If DNSSEC is so useful, why is its deployment non-existent for top domains?
It is actually unclear whether DNSSEC is "what we want".
Right now, the certification of Web site, i.e. how a Web browser makes sure that it talks to the right site (when doing HTTPS) is done with digital certificates emitted from about a hundred of Root Certification Authorities. The root CA are entities who decided to go into the certificate issuance business, and what makes the hundred-or-so special is that they made a deal with Microsoft/Apple/Mozilla/Google so as to include their public key in the "trusted" store of every browser (or operating system). The deal includes a lot of legalistic gizmos and insurances.
Though often criticized for its opacity, public cost of individual certificates, and a few well-publicized blunders (lookup "Comodo" and "DigiNotar"), the PKI system tends to work, in an economic sense: commercial sites use them, and the CA are very rarely attacked (most attacks are about inducing the gullible user into ignoring the scary warnings that the browser emits when it finds something fishy with the certificates, rather than going to the trouble of subverting an existing CA). There is then relatively little incentive to change things (that is, there are a lot of people who would prefer another system for a variety of reasons, but, ultimately, these things are decided by those who pay for it).
DNSSEC is about taking these root CA out of the loop, and instead give the certification power to the people who maintain the DNS (the mapping from server names to IP addresses), in such a way that the two structures would be bound together: domain name inheritance (with the notion of "sub-domain") would be merged with PKI inheritance (with the notion of "intermediate CA").
It is unclear whether the new tenants would be more competent at the CA business than the previous; as I said, the actual system works already quite well, and certification is not the same craft as mapping names to addresses. It is also unclear whether such concentration of powers is really a good thing. For the big players, it would not change anything: Verisign-the-CA and Verisign-the-registrar are both Verisign.
On the technical side of things, DNSSEC offers easy distribution of certificates (aka "signed bindings of identities to public keys") through the DNS system, but that's not a problem which needed to be solved: right now, any SSL/TLS server happily sends his certificate chain as part of the initial handshake, and it works well.
Thus, given the uncertainties about the goodness of DNSSEC, and the lack of flagrant issues with the existing PKI, it is no wonder that deployment is deemed non-urgent by the big companies. Let's get IPv6 working first.
As indicated by the comments below, DNSSEC has some value as itself for authenticating DNS information, which blocks DNS poisoning. DNS poisoning is the easy way to do a Man-in-the-Middle attack, but it would be wrong to believe that this solves MiTM issues; it just makes things a bit harder for the attacker (e.g. the attacker must use a WiFI-pineapple instead of simply abusing a hole in an existing WiFi hotspot). Getting guarantees about the mapping of a name to a given IP address does not get you far if you cannot know whether a given packet really comes from the IP address which is written in its header.
Either way, it does not provide much added value to the big servers, and that's sufficient to explain their reluctance.
(DNSSEC has military value, though: by preventing DNS poisoning, it helps in defending against big denial-of-service attacks that could be part of some global electronic warfare. I expect DNSSEC to be supported by governments, not by big companies -- but the days or ARPANET are long gone, and the Internet is the territory of private ventures nowadays.)
The only thing wrong with DNSSEC is that it's new, DNS is (obviously) important and people are reluctant to mess with their DNS setup. If your DNSSEC deployment goes wrong you could loose your entire internet presence.
As to why you'd want to authenticate DNS lookups, read this paper on how the great firewall leaks onto users outside of China:
http://www.sigcomm.org/sites/default/files/ccr/papers/2012/July/2317307-2317311.pdf
It's not just China that mucks about with DNS, anyone with access to the traffic between a client, the client's resolver or the resolver and your dns servers can alter responses as well.
Certificates for websites are only a small part of the puzzle here.
8 Years Later:
I must conclude they know something bad about DNSSEC that overweights the benefits offered by it.
Not necessarily. Just as any other technology, the question is what incentives are there for involved stakeholders?. If you take a look at ICANN's DNSSEC report you can see that nearly all TLDs currently support DNSSEC.
So why consumers do not use it? Well it is also not easy to answer. In general if you don't want to go through the hassle of running your own name servers, you are dependent on the registrar to take care of some features such as DNSSEC. A Study by Chung et al. in 2017 [1] showed that "only three of the top 20 registrars support DNSSEC when they are the DNS operator". Even if your name server is properly configured to use DNSSEC, there is no guarantee that users use (recursive) resolvers that are DNSSEC-aware and properly verify DNSSEC records [2].
Poor security usability for the end-users is probably another negative incentive for potential adopters. Compared with TLS, where you'd get warnings and errors directly in your browser in case of invalid certificates, there is no visual cue for DNSSEC (you can check if a website is signed or if your resolver validates DNSSEC on https://internet.nl/).
To give another twist to the whole story, lack of DNSSEC is sometimes desired by some parties. DNS poisoning for example opens the door for domain impersonation which can also grant you a domain validation (DV) certificate [3] which practically enables you to spoof a legitimate entity even with a valid certificate (green padlock in the address bar). Another example is the tr TLD which does not support DNSSEC; now combine this with how the government of Turkey once abused DNS for censorship you can draw your own conclusions.
[...] and that you can walk DNSSEC records and find out all records in your domain.
This is not the case anymore with NSEC3.
Update:
I forgot to mention RFC 3833, which not only enumerates DNS security threats, but also weaknesses of DNSSEC:
- DNSSEC is complex to implement.
- DNSSEC significantly increases the size of DNS response packets.
- DNSSEC answer validation increases the resolver's work load.
- Like DNS itself, DNSSEC's trust model is almost totally hierarchical.
- Key rollover at the root is really hard.
- DNSSEC creates a requirement of loose time synchronization.
- The possible existence of wildcard RRs in a zone complicates the authenticated denial mechanism considerably.
[1] Chung, T., Levin, D., Van Rijswijk-Deij, R., Maggs, B. M., Wilson, C., Choffnes, D., & Mislove, A. (2017). Understanding the role of registrars in DNSSEC deployment. Proceedings of the ACM SIGCOMM Internet Measurement Conference, IMC, Part F1319(July), 369–383. https://doi.org/10.1145/3131365.3131373
[2] Chung, T., Van Rijswijk-Deij, R., Chandrasekaran, B., Choffnes, D., Levin, D., Maggs, B. M., Mislove, A., & Wilson, C. (2017). A longitudinal, end-to-end view of the DNSSEC ecosystem. Proceedings of the 26th USENIX Security Symposium, 1307–1322.
[3] Schwittmann, L., Wander, M., & Weis, T. (2019). Domain impersonation is feasible: A study of CA domain validation vulnerabilities. Proceedings - 4th IEEE European Symposium on Security and Privacy, EURO S and P 2019, 544–559. https://doi.org/10.1109/EuroSP.2019.00046