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

[Shumon Huque]

On Tue, Jul 18, 2023 at 3:29 PM Viktor Dukhovni <ietf-dane at dukhovni.org>
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20230718/3e9bf2ab/attachment.html>