[dns-operations] slack.com bogus
puneets at google.com
Fri Oct 1 16:03:45 UTC 2021
Some information on what happened during this incident with the Google
Public DNS service.
* GPDNS did not configure an NTA for slack.com
* We observed a small percentage of SERVFAILs during 10:05-10:47 AM PT
on 20210930. Which was fixed by
* a number of user-initiated cache flush requests for slack.com
records (dname, ds, a, soa) between 10:46 AM to 11:28 AM PT on
Our general policy on NTAs is to only add them after evaluating the
specific scenario. We never add them by default.
On Thu, Sep 30, 2021 at 3:20 PM Viktor Dukhovni <ietf-dane at dukhovni.org> wrote:
> On Thu, Sep 30, 2021 at 02:31:32PM -0400, vom513 wrote:
> > I see it as broken at home on my validating BIND instance (I get SERVFAIL).
> > Interesting (at least to me) - checking 22.214.171.124 and 126.96.36.199 I get A
> > records back just fine. However no ‘ad’ flag (using dig). Other
> > DNSSEC signed zones still give ad off quad-8/quad-1 though.
> > So perhaps a dumb question - could Google and Cloudflare be hitting
> > some kind of “manual overrride” to not validate a given zone - i.e.
> > human intervention / look the other way ?
> > Or is there a more technical explanation that I could be missing ?
> It suffices to cap DS RRSet TTLs well below the .COM TLDs 24 hour
> default. If they cap TTLs at say 1 hour, the issue would have been
> resolved 1 hour after the DS RRSet was deleted from the .COM zone.
> Of course the DS RRSet might also have been manually flushed from the
> cache, as special treatment for "slack.com", given their popularity and
> the verifiable deletion of the DS records.
> A final possibility is automatic refresh of DS records for domains that
> go bogus.
> So there are a number of ways to reduce the impact duration to below the
> full ~1 day maximum.
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
More information about the dns-operations