Just so we’re clear: my most reached-for argument against DNSSEC is that it’s a global PKI de jure controlled by world governments (and, most importantly, by the “Five Eyes” IC).
My backup argument is that it’s a reliabilty nightmare. It has just an astonishing track record for causing durable, material outages for companies that enable it, stemming from the sensitive place in our network stack DNS occupies, and the fact that the stack wasn’t designed to put security policy in that place.
My standard nerdy argument against DNSSEC is that it doesn’t actually address any threats: it’s a server-to-server protocol (this still surprises people, who think that DNSSEC is somehow protecting them when they resolve off 8.8.8.8) and the modal hijacking attack today is registrar phishing.
My economic argument against DNSSEC is that nobody uses it --- take a list of the top 100, 500, 1000 zones and write a shell script to have `dig` check for DNSSEC records and you’ll find that virtually nothing you use is signed; without signatures the protocol can’t do anything for you, so you’re just signing up for outages.
But none of these are my real problem with it.
My real problem with it is that the cryptography is awful. DNSSEC is not a system you would design with a 2020 understanding of how to leverage encryption at scale; it’s not even a good design for 2015.
Despite its minimal deployment, DNSSEC might be the Internet’s more virulent vector for getting 1990s more 1990s cryptography deployed.
@tqbf without DNS Transparency and an MDSP/CCADB/CABF, I have considerably less faith in registrars as a root of trust than certificate authorities
@Natanael_L @tqbf @matt well you see, they’re separate multibillion dollar businesses and markets ran by separate people with different legal requirements