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

Viktor Dukhovni ietf-dane at dukhovni.org
Wed Jul 12 02:51:47 UTC 2023


On Tue, Jul 11, 2023 at 05:24:57PM -0700, Gavin McCullagh wrote:

> > 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.

For most .COM RRsets the RRSIG lifetime is 7 days, 1 hour and 10
minutes:

    com. IN RRSIG NS 8 1 172800 20230717042337 20230710031337 46551 com. [omitted]
    verisign.com. IN RRSIG DS 8 2 86400 20230716041715 20230709030715 46551 com. [omitted]

[ The one exception seems to be the zone apex DNSKEY with 15 days and
  minutes. ]

In .COM CZDS zone file snapshot of .COM from ~midnight UTC 2023-07-11
the range of non-apex RRSIG inception times was:

    20230707025004 – 20230710225021

With corresponding expiration times:

    20230714040004 – 20230718000021

With expiration of the oldest RRSIGS 3 days and 4 hours away, and the
newest a full 7 days.

My impression is that not all the signatures had expired during the
incident, and, for example, the "validity" of insecure delegations in
the middle of an unexpired NSEC3 range was unaffected (leaving
potentially stale NS records, NXDOMAIN for newly registered domains, ...
as the residual issue).

Yes, likely the blast radius from the RRSIG expiration was higher than
from stale records, since much of the zone is quite static otherwise.
On the other hand, this way the issue was identified sooner... :-)

-- 
    Viktor.


More information about the dns-operations mailing list