On 9/30/21 2:42 PM, Viktor Dukhovni wrote:
On 30 Sep 2021, at 2:00 pm, Peter van Dijk <[email protected]> wrote:
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.
In more detail, it sure looks like they may have deployed their DS RRSet
prematurely for the first time today (with the domain initially signed and
working at that time) and then made the mistake of quickly yanking the DS
records. I see no prior history in the DNSSEC/DANE survey data of DS
records for slack.com.
As you probably realize, but others may not, yanking the DS records per
se didn't kill them; it was the fact that they yanked the DS records
*and* made the mistake of pulling their DNSKEY and RRSIG records from
their zone.
Given that there are still reports of resolvers out there with cached DS
records, has anyone who may be in contact with the Slack admins advised
them to bring back the DNSKEY records and RRSIGs without bringing back
the DS records? Once the negative cache ttl expires (5 min according to
the SOA minimum), people will start resolving and validating stuff
again, rather than having to force-flush or wait for the 24 hour DS TTL
to expire. (By my calculation, we still have 17 hours to go, vs. 5
minutes.)
michael
_______________________________________________
dns-operations mailing list
[email protected]
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
