A many-splendored infrasec disaster. Count all the ways DNSSEC sabotaged this infra team.
https://twitter.com/koenrh/status/1465274920691249159
DNSSEC quietly changes the behavior of resolvers even before we get to signature checking — they stop honoring CNAMEs at zone apexes. Even before you push the DS record that “links” your zone to the USG’s PKI. Of course! Who would think otherwise.
Does that DS record get cached by resolvers or not? Who knows! Nobody uses DNSSEC, so if you’re Slack, you have the fun project of being the one of the first serious sites with a modern DNS configuration to actually turn it on. Whee!
What would a 1990s crypto protocol be without several different types of keys each with different key storage? You thought the KSKs and ZSKs were both recoverable, so you could re-sign after pulling your DS? Nah.
My favorite bit here is the hour(s) during which the Slack DNS team is trying to figure out whether pushing a new DS to link Slack.com back to the USG PKI will mitigate the disaster or prolong it. NOBODY KNOWS.
Oh, and apparently Slack is the first company ever to attempt DNSSEC on AWS with wildcard records, which we surmise from the fact that wildcard records break when DNSSEC is enabled at AWS.
A day-long outage, and why? Because a USG FedRAMP document suggests it’s required. Meanwhile here’s what Cloud.gov has to say about DNSSEC (tl;dr: don’t): cloud.gov/docs/complianc…
Coda: they still haven’t re-enabled DNSSEC.
• • •
Missing some Tweet in this thread? You can try to
force a refresh
