> In BIND itself SERVFAIL cache has 1 second TTL and keyed by (class, > qname, qtype). Consequently, a typical web browser query for > (portal.internal.example.com A+AAAA+HTTPS) will cause 6 outgoing > queries to the auth, 6 cache SERVFAIL entries for 1 second, rinse > and repeat until I close the browser tab I forgotten about.
It seems that the fundamental problem here is that we don't have a TTL for SERVFAIL. If the upstream resolver has support for 'NS .' then it could report the TTL of the NS record as the TTL of the SERVFAIL. Forwarders could use the TTL of the SERVFAIL they get from upstream instead of a hard coded value. There are plenty of DNSSEC failures that are not going away soon. No need to keep trying every second. Adding a TTL to SERVFAIL will take time but maybe in the future it will allow us to use SERVFAIL (or other error codes) as a more useful signal that something is really not there and that the situation is not expected to change any time soon. I'll leave out the encoding of the SERVFAIL, I'm sure we can come up with something. _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
