Comment by cyberax
3 hours ago
> DNSSEC mistakes take your entire domain off the Internet, as if it had never existed.
DNS mistakes take your entire domain off the Internet, as if it had never existed.
I'm preparing a proposal to add an advisory mode for DNSSEC. This will solve a lot of operational issues with its deployment. Enabling it will not have to be a leap of faith anymore.
I haven't had to edit the DNS zones for most of my domains in many years. DNSSEC adds an expiring, rotating key change regime to it. If you screw it up, the screwup is cached everywhere, and the failure mode isn't like HTTPS, where you get an annoying popup: you just get NXDOMAIN, as if your domain never existed.
This isn't so much as a scary story I'm telling so much as it is an empirically observable fact; it's happened many times, to very important domains, over the last several years.
I run DNSSEC (to facilitate DANE) and with regards to DNSSEC I haven't had to manually edit my zones in years either. Unlike yourself I don't consider DNSSEC deployment or ZSK rotation / KSK roll-over scary or complex, and seeing an adept technician dole out warnings on the level of "don't run with scissors" is pretty peculiar.
Your objections basically boil down to: DNS is dangerous, and DNSSEC _is_ DNS. This is fair, but the conclusion for me is that we need to make _DNS_ more reliable. Not to keep treating it as a fragile Ming Dynasty vase.
In particular, the long TTL of DNS records itself is a historic artifact and should be phased out. There's absolutely no reason to keep it above ~15 minutes for the leaf zones. The overhead of doing additional DNS lookups is completely negligible.
> This isn't so much as a scary story I'm telling so much as it is an empirically observable fact; it's happened many times, to very important domains, over the last several years.
So has the TLS cert expiration. And while you can (usually) click through it in browsers, it's not the case for mobile apps or for IoT/embedded devices. Or even for JS-rich webapps that use XMLHttpRequest/fetch.
And we keep making Internet more fragile with the ".well-known" subtrees that are served over TLS. It's also now trivial for me to get a certificate for most domains if I can MITM their network.
Edit: BTW, what is exactly _expiring_ in DNSSEC? I've been using the same private key on my HSM for DNSSEC signing for the last decade. You also can set up signing once, and then never touch it.
This drills into the core problem: technologists like you look at DNSSEC and say "there is a problem, something must be done, this is something". But it's not enough to identify a problem and solution. The solution has to be worth the cost. Rollout can't be more costly than the original problem.
There's ample evidence that the cost/benefit math simply doesn't work out for DNSSEC.
You can design new DNSSECs with different cost profiles. I think a problem you'll run into is that the cost of the problem it solves is very low, so you won't have much headroom to maneuver in. But I'm not reflexively against ground-up retakes on DNSSEC.
Where you'll see viscerally negative takes from me is on attempts to take the current gravely flawed design --- offline signers+authenticated denial --- as a basis for those new solutions. The DNSSEC we're working with now has failed in the marketplace. In fact, it's failed more comprehensively than any IETF technology ever attempted: DNSSEC dates back into the early-mid 1990s. It's long past time to cut bait.
10 replies →