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

[Gavin McCullagh]

>




On Tue, Jul 11, 2023, 4:30 PM Viktor Dukhovni <ietf-dane at dukhovni.org>
wrote:

> On Tue, Jul 11, 2023 at 10:24:21PM +0000, Wessels, Duane wrote:
>
> > Over the weekend, this caused an issue that may have affected the
> > ability of some internet users in the region to reach some .com and
> > .net domains, as DNSSEC signatures on the site began expiring. The
> > issue was resolved by powering off the site’s peering router, causing
> > the anycast route announcement to be withdrawn and traffic to be
> > directed to other sites.
>
> I should note that DNSSEC was not the only fallout from outdated zone
> files.  Some delegations had stale NS records, for which the outdated
> nameservers were already returning REFUSED (or outdated answers).
>
> Consequently, some users unlucky enough to have switched providers or
> moved to new NS hosts at the same a provider after the site was cut off
> from updates also observed some issues, whether or not DNSSEC happened
> to be involved.


That is true of course, but the magnitude of this event was made much worse
by dnssec.  The entire COM and NET zones being bogus (including the
unsigned delegations) is very different to the few that saw record changes
in the prior 1-2 days.

What surprised me was, we saw Unbound persistently caching stale rrsigs and
returning servfails for a busy second level domain, even though the
majority of alternate nameservers on offer were not stale.

Does Unbound retry another nameserver when it sees a bogus response with
expired rrsigs?  Does it retry enough to guarantee hitting a good
nameserver here?

Gavin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20230711/810c1097/attachment.html>