[dns-operations] DNS .com/.net resolution problems in the Asia/Pacific region

Viktor Dukhovni ietf-dane at dukhovni.org
Thu Jul 13 20:14:33 UTC 2023

On Thu, Jul 13, 2023 at 12:16:37PM -0700, Gavin McCullagh wrote:

> When faced with ~4x obviously bogus, broken nameservers (the stale pop) and
> ~9x fresh working nameservers with valid signatures, the DNSSEC RFCs appear
> to specify (and Unbound appears to implement) that resolvers must accept
> and cache the obviously bogus (expired rrsig) answers and return SERVFAIL
> to clients until those bogus answers expire (apparently 24 hours later in
> this case?), rather than immediately considering those responses invalid,
> those nameservers as lame and retrying against another - assuming this
> response is either coming from an attacker or from a broken nameserver.

I don't believe that's a valid reading of the DNSSEC RFCs.  Bogus
answers are not cached by the resolver I'm working on these days, beyond
the usual query rate limits for failures.

And to the extend that a only some servers have stale data, I am also
working to make sure that we'll try go get a better answer from another
server.  Some resolvers already do.

> Obviously we need to be careful about creating retry storms, but that retry
> storm is pretty much equivalent to what would happen if that PoP were to
> return SERVFAIL or not respond, so that doesn't seem like a new problem.

Correct.  Within reasonable retry limit counts and error response
hold-downs, bad/stale/... data from a single server should not be final
whether it is DNSSEC-related or not.


More information about the dns-operations mailing list