The argument for it (not saying I accept it) is that the definition of the "authentic site" largely resides in the database of the DNS registrars anyway.
Currently, many CAs authenticate new applicants primarily on the basis of this "domain control", i.e., can they receive an email at this domain. So DNSSEC wouldn't be changing anything there.
IMHO, the idea of providing cryptographic authentication for DNS records isn't inherently a bad one and it's only natural that it would follow the same hierarchy as the name delegation itself.
In one sense it delegates more freedom than the CA system does (assuming you don't purchase yourself a sub-CA). However, in other fundamental ways it represents a highly centralized system of control.
DNSSEC advocates (not saying you're one) tend to talk about the idea of cryptographic authentication of DNS records as if it were free. But it's not free. It will cost many tens of millions of dollars. It will contribute to the instability of the Internet as a whole as well-meaning but necessarily inexpert administrators misconfigure their zones. And because DNS is at a lower layer of the stack than TLS, those failures will be more severe.
For instance, read any tutorial on socket programming, or browse socket code on Github or Google Code Search. Look how a DNS name is normally resolved in code: by calling gethostbyname(name). Look how the return value of that call is handled: either the struct hostent it returns is NULL, in which case "host not found", or it's non-NULL, in which case the domain name is good. Where's the error channel?
There are DNSSEC advocates --- presumably none of whom have shipped a product in C before --- who talk as if this is a minor detail. But look at Daniel J. Bernstein's "ipv6mess" article:
How do we reach the magic moment? How do we teach every server on the Internet to talk to clients on public IPv6 addresses? How do we teach every client on the Internet to talk to servers on public IPv6 addresses?
Answer: We go through every place that 4-byte IPv4 addresses appear, and allow 16-byte IPv6 addresses in the same place.
Isn't it the same deal for DNS? Aren't we talking about either forklifting out or breaking huge amounts of deployed code?
And to what end? DNSSEC doesn't solve the PKI problem we have on the Internet. When people in the Czech Republic go to Google, aren't they often going to GOOGLE.CZ? When people in Italy go to Amazon, don't they go to AMAZON.IT? Who controls .CZ? .IT? .COM? Certainly not Amazon and Google.
What we have on the Internet is a failure of security policy. It's a human factors problem and a UX problem, not a failure of the core Internet protocols. By acting like a band-aid on those core protocols is going to fix the problem, we:
* defer the real solution to the problem for another 10 years while we wait-and-see whether DNSSEC helps (hint: it won't really)
* make it even harder to apply UX solutions to the problem by pushing the decisions that need to be made further down the stack
* incur costs and instability and yes probably a good deal of security flaws to no good end.
Look how a DNS name is normally resolved in code: by calling gethostbyname(name). Look how the return value of that call is handled: either the struct hostent it returns is NULL, in which case "host not found", or it's non-NULL, in which case the domain name is good. Where's the error channel?
Don't forget the influence of Mozilla, Google, Microsoft, and Apple. While they may not own even the majority of the lines of code, the code they do own is disproportionately visible.
Some of their stuff actually does its own name resolution, or even provides the implementation for a whole operating system. I believe some of them are shipping some actual DNSSEC client code today.
Combine that with the work done by ISC and this thing isn't exactly alone whistling in the wind.
There are DNSSEC advocates --- presumably none of whom have shipped a product in C before --- who talk as if this is a minor detail.
Hmm, well Paul Vixie counts at least double in my book.
Isn't it the same deal for DNS? Aren't we talking about either forklifting out or breaking huge amounts of deployed code?
Sure, it will probably take 10 years before the absence of DNSSEC data can be interpreted as a name resolution failure. But technology can move a lot faster now that MS IE and Windows doesn't have 90% market share on the client side anymore.
But there's only so much hand-picking of your examples that you can get away with. Your argument would be stronger if it accounted for more data points.
We go through every place that 4-byte IPv4 addresses appear, and allow 16-byte IPv6 addresses in the same place. Isn't it the same deal for DNS?
Actually, I don't think so. The intermediate state on the upgrade path for DNSSEC is infinitely easier than for IPv6, which is what DJB seems to be pointing out.
Of course, in many circumstances the real security benefits are not obtained as long as the attacker can simply strip off the DNSSEC information and downgrade the client back to 'compatible mode'. But this seems to be an inherent difficulty in strengthening authentication in any diverse ecosystem of endpoints.
You're right that unlike IPv6, DNSSEC does not require a unanimous "flag day" upgrade. And you're right that that's relevant. Partly, this is because by design, DNSSEC only protects DNSSEC servers; the path between a modern browser and the DNS server configured by DHCP is not protected by DNSSEC.
At the risk of bucketing myself as a crackpot: I'm actually not a big fan of IPv6 either. I don't believe that in 50 years anyone is going to care what an IP address is; we'll have long since built new overlays on top of whatever transports we come up with, and IP will be an archeological curiosity.
The network should be dumb; it's the endpoints that need to be smart.
I agree completely about the dumb network. Security, in particular, lives in the endpoints.
But still, net-boot BIOSes and BOOTP/DHCP protocols have been around since 1985 (RFC 951). They show no signs of going away. Possibly the problem of bootstrapping the configuration and security relationships will be with us as long as there are security boundaries on the networks.
And there will be security boundaries on networks as long as there are mediated boundaries in the real world.
Currently, many CAs authenticate new applicants primarily on the basis of this "domain control", i.e., can they receive an email at this domain. So DNSSEC wouldn't be changing anything there.
IMHO, the idea of providing cryptographic authentication for DNS records isn't inherently a bad one and it's only natural that it would follow the same hierarchy as the name delegation itself.
In one sense it delegates more freedom than the CA system does (assuming you don't purchase yourself a sub-CA). However, in other fundamental ways it represents a highly centralized system of control.