## page was copied from DnsTemplate ##master-page:HelpTemplate === watchA === <> <> Peter van Dijk peter.van.dijk at powerdns.com Thu Sep 30 18:00:33 UTC 2021 {{{ Judging from dnsviz, a DS was present in the .com zone for slack.com around 15:25 UTC today, and records inside slack.com were correctly signed with the related KSK/ZSK set. Judging from the DS as I see it coming out of some resolvers, the DS is about 15 hours old at this point (so, introduced around 03:15 UTC I think). Those cached DSes still have 10 hours to go. However, the DS is gone from the .com zone, and the DNSKEYs and RRSIGs are also gone. Hence, slack.com is Bogus for a big part of the Internet viewer population. }}} https://lists.dns-oarc.net/pipermail/dns-operations/2021-September/021346.html {{{ Viktor Dukhovni ietf-dane at dukhovni.org Thu Sep 30 19:19:24 UTC 2021 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. }}} == aws bug == https://lists.dns-oarc.net/pipermail/dns-operations/2021-September/021362.html {{{ On Thu, 2021-09-30 at 15:31 -0700, Michael Sinatra wrote: > Once the negative cache ttl expires (5 min according to > the SOA minimum) It appears AWS DNS has a bug here - their negative responses advertise the 900 second TTL on the SOA records in negative responses, instead of the 300 second MINIMUM. This, of course, changes nothing about your argument. (But it would be nice if AWS fixed this.) }}} ---- CategoryDns CategoryWatch CategoryTemplate