On Tue, Jul 18, 2023 at 3:29 PM Viktor Dukhovni <[email protected]> wrote:
> On Tue, Jul 18, 2023 at 08:54:04PM +0200, Ondřej Surý wrote: > > > With my implementor’s hat on, I think this is wrong approach. It > > (again) adds a complexity to the resolvers and yet again based > > (mostly) on isolated incident. I really don’t want yet another > > “serve-stale” in the resolvers. I have to yet see an evidence that > > serve-stale has helped anything since the original incident, but now > > every resolver has to have it because people want it. > > How is this akin to "serve stale"? We're talking about retrying > response that fail to validate, just one might/would retry a response > that is "REFUSED", "SERVFAIL", has TC=1 over UDP, contains garbage, ... > > The "serve stale" situation is quite different, here substantial new > logic is required, whereas with invalid responses, it is just a matter > of trying the next server up to some reasonable work limit. > > Retries to reach a better authoritative server are core element of DNS > resilience in the face if inevitable partial degradation of service. > Yes, I agree. A resolver can't really tell that a response with an expired signature wasn't an attacker trying to replay old data. For robustness against attacks, it must re-query other available other servers if they exist. Also, I was under the impression that most resolvers already had this robust behavior. Since Unbound was mentioned, I just tested an unbound resolver against a test DNS record that I have provisioned with an intentionally expired DNSSEC signature - it sent queries to all 4 servers for the zone before giving up and returning SERVFAIL. Shumon.
_______________________________________________ dns-operations mailing list [email protected] https://lists.dns-oarc.net/mailman/listinfo/dns-operations
