This post also has an FAQ.

DNSSEC is Unnecessary

All secure crypto on the Internet assumes that the DNS lookup from names to IP addresses are insecure. Securing those DNS lookups therefore enables no meaningful security. DNSSEC does make some attacks against insecure sites harder. But it doesn’t make those attacks infeasible, so sites still need to adopt secure transports like TLS. With TLS properly configured, DNSSEC adds nothing.

Take “domain-validated TLS certificates”. Some TLS CAs will sign certificates based solely on the requester’s ability to receive a confidential email sent to a domain. DNSSEC makes attacks against this scheme harder. But domain-validated certificates remain insecure, because SMTP is itself insecure. Put differently: the problem is “validating domain ownership via email” in the first place, not that the DNS is insecure.

DNSSEC is a Government-Controlled PKI

Securing DNS lookups isn’t a high-priority Closing browser RCEs or fixing TLS crypto are high-priority tasks. task. DNSSEC proponents recognize this. And, for historical reasons, DNSSEC proponents disdain the X.509 machinery behind the TLS CA. DNSSEC’s real job is thus to replace the TLS CA system. This plan is called DANE.

TLS CAs do need to be replaced. But it’s hard to imagine a worse replacement than DANE.

For something as harebrained as the CA system, remarkably few criminal breaches trace back to it. The real threat to CAs is “the global adversary” i.e., NSA. . Whichever system replaces CAs needs to make TLS more resilient to government attacks. And governments control the DNS.

Even in a future where the USG decisively cedes control of the DNS roots, it will retain control of the most important TLDs Amusing fact: the biggest player among TLS CAs? Also the most important DNSSEC player. . And governments with even fewer scruples will control other important TLDs. In a world where users rely on DANE, those governments have much of the same cryptographic authority as the CAs do now. Had DNSSEC been deployed 5 years ago, Muammar Gaddafi would have controlled BIT.LY’s TLS keys.

DNSSEC is Cryptographically Weak

The original DNSSEC design is two decades old; the first drafts I can find are from 1994. Real-world DNSSEC therefore relies on RSA with PKCS1v15 padding. The deployed system is littered with 1024-bit keys.

No cryptosystem created in 2015 would share DNSSEC’s design. A modern PKI would almost certainly be based on modern elliptic curve signature schemes, techniques for which have coalesced only in the last few years.

DNSSEC has virtually no real-world deployment. It makes no engineering sense, knowing what we know now about cryptography, to instigate a massive new deployment of obsolete crypto.

DNSSEC is Expensive To Adopt

Today, DNS lookups either succeed or fail. And there are generally two reasons a lookup fails: the name doesn’t exist, or the requestor lacks connectivity to the Internet. Network software is built around those assumptions.

DNSSEC changes all of that. It adds two new failure cases: the requestor could be (but probably isn’t) under attack, or everything is fine with the name except that its configuration has expired. Virtually no network software is equipped to handle those cases.

Trouble is, software must handle those cases. End-users excoriate browser vendors for making it harder to “click through” certificate warnings, which are common. So frustrating were these warnings that the authors of curl egregiously broke their own API to appease programmers. So there’s no reason to believe that hard failures for DNS lookups will be acceptable to users.

But the code that handles lookups today is buried deep in the lowest levels of application network code, and is rarely if ever wired for user interface. Some very popular standard library interfaces (looking at you, gethostbyname(3)) to DNS can’t support DNSSEC failure cases at all.

A lot of code will need to be rewritten to make DNSSEC workable.

DNSSEC is Expensive To Deploy

DNSSEC is harder to deploy than TLS. TLS is hard to deploy (look how many guides sysadmins and devops teams write to relate their experience doing it). It’s not hard to find out what a competent devops person makes. Do the math.

DNSSEC is Incomplete

You’d think, for all its deployment expense, the forklifting out of incompatible networking code, and the required adoption of a government PKI running 1990s crypto, DNSSEC would at least nail its marginally valuable core use case.

Nope.

DNSSEC doesn’t secure browser DNS lookups.

In fact, it does nothing for any of the “last mile” of DNS lookups: the link between software and DNS servers. It’s a server-to-server protocol.

Why? Because there are two DNS security problems. The first is somewhat esoteric, and allows servers to exploit the way DNS records refer to one another in order to add a bogus record for VICTIM.ORG to a lookup for EVIL.NET. The latter is obvious and allows any attacker with access to the network to simply spoof entire DNS responses. The committee designing DNSSEC split the baby and chose the former problem over the latter.

Even if DNSSEC was deployed universally and every zone on the Internet was signed, a coffee-shop attacker would still be able to use DNS to man-in-the-middle browsers.

DNSSEC is Unsafe

DNSSEC builds on the original DNS database. So applications will need to distinguish between secure DNSSEC records and or insecure DNS records. To solve this problem, DNSSEC provides a cryptographically-secure “no such host” response.

But DNSSEC is designed for offline signers; it doesn’t encrypt on the fly. Meanwhile, there are infinite nonexistent hostnames. But all you can sign offline are the hostnames that do exist. So to provide authenticated denial, those signed records “chain”. You cryptographically verify that a record doesn’t exist by observing that no other record chains to it.

Authenticated denial. Offline signers. Secret hostnames. Pick two.

In the past couple years (reminder: DNSSEC has been “ready to deploy” for almost 15 years), the DNSSEC standards project has solved this problem, if we accept as a “solution” “NSEC3 and “minimum covering NSEC records” with online signers managing DNS zones as a sort of bizarro Unix password file in which fake records are added at random to foil password crackers Confused? Don’t worry, there’s an NSEC5 coming too. . This mode of deployment is, of course, not the default.

For everyone who accepts the default, every hostname in their DNS zones are public information. This works for the kind of person who works on standardizing DNS extensions, because their hostnames are things like “dec-multia-in-my-basement.greybeard.com”. It does not work so well for Bank of America.

DNSSEC is Architecturally Unsound

Don’t take my word for this; here’s 1981’s End-To-End Arguments In System Design, one of the foundational papers of the Internet:

The function in question [security] can completely and correctly be implemented only with the knowledge and help of the application standing at the end points of the communication system. Therefore, providing that questioned function [security] as a feature of the communication system itself is not possible.

A casual look at the last 20 years of security history backs this up: effective security is almost invariably application-level and receives no real support from the network itself.

There’s a simple reason for this: security is about policy, and policy is about choices. DNSSEC tries to make a single set of choices for the entire Internet. We all know what to expect: a frankensystem that decisively solves no problems while imposing painful tradeoffs and concessions on everyone. How could US government IT not love it?

DNSSEC doesn’t have to happen. Don’t support it.

If you’re running systems carefully today, no security problem you have gets solved by deploying DNSSEC. But lots of other problems —– software maintenance, network operations, user support, protecting your secrets from NSA/GCHQ —– get harder.

When it suits DNSSEC boosters to say it, “DNSSEC has been ready to deploy for over a decade”. Other times, “the root zones have only been signed since 2010”. The protocol changed in 1998, 2000, 2001 (“DNSSEC-bis”), 2003 (“the typecode roll”), 2004 (NSEC3, the DNS password file), and 2005. But it still retains the genetic imprint of the first versions of the protocol, designed when serious cryptography was deemed too expensive for DNS servers and before HMAC was invented, let alone deterministic ECC signatures.

In the years since the USG paid TIS to solve DNS security, the Internet routed around the damage. TLS isn’t a beautiful system, but its problems don’t stem from the DNS and aren’t solvable in the DNS. It’s protected more people than DNSSEC ever will.

The Internet loses nothing if it declares a TKO on DNSSEC and starts fresh. There are better DNS security proposals circulating already. They tend to start at the browser and work their way back to the roots. Support those proposals, and keep DNSSEC code off your servers.