> 1) That would do nothing to fix resolvers that had already cached NSEC responses lacking type maps.

The TTL for NSEC records are presumably way lower than the TTL for the DS records.

> 2) That presumes the wildcard record was superfluous and could have been replaced with a simple A record for a single or small number of records. Would love to see a citation supporting that.

It’s theoretically possible that it would not have worked for all cases, but that is, in my experience, very unlikely.

> Any way you slice it, there was no quick way to fully recover from this bug once they hit it

The bug seems to me to have been reasonably easy to mitigate, but their problem was that Slack did not know what they were doing. Thu bug itself was minor, but Slack tried to fix it by stopping to serve DNSSEC-signed DNS data, while long-TTL DS records were still being unexpired in the world. This is the worst possible thing you could do.

> Of the top 100 domains -- the operators you would assume would be the most concerned about DNS response poisoning -- *six* have turned DNSSEC on.

1. That number used to be zero, as tptacek liked to point out.

2. The huge operators often have fundamentally different security priorities than regular companies and users.

3. People said the same about IPv6 and SSL, which were also very slow to adopt. But they are all climbing.