This grumpy troll has long been miffed by the state of the X.509 trust system and the power placed in Certificate Authorities. See, for instance, https://lopsa.org/SSLIntro from October 2006; written as a guide for LOPSA members, which goes into the trust models of Kerberos, PGP and SSL's Public Key Infrastructure (PKI).
Also, a CA certificate can include nameConstraints, which restricts what names the CA claims authority over. Most CAs claim global authority and most clients don't appear to offer a way to impose name constraints by local policy instead of based on the certificate. As a result, a CA in Brazil can issue an SSL cert for www.barcleys-bank.co.uk and it's up to you to spot the mis-spelling. Equally, a British CA can issue certificates for sites under .br. This is insane.
There have been other grumblings, your humble troll can try to find which ones are on the record, but that's not the point of this post.
This troll is even more concerned that in the outcry over the DigiNotar compromise (see, for instance, LWN on *.google.com and diginotar damage disclosure, by "ioerror"), part of the resulting clamour is to migrate to a system such as DANE ("DNS-based Authentication of Named Entities"), in which DNSSEC is used to leverage the existing DNS federation system to also provide the trust anchors for the X.509 certs used to then secure data flowing to an end-point (eg, over TLS).
In The DNS root zone, international governance, ICANN and DNSSEC this troll grumped about the problems of moving to DNSSEC from the root zone and the actual balances of power in controlling the DNS, rather than what's stated on paper; I argued in favour of leaving the US government nominally in control of the root zone. But the situation is worse than this.
Various governments have tried to control what can appear in the DNS; China is infamous for its DNS proxies which ISPs in that nation are required to use, and how those proxies drop results. US government agencies have been merrily seizing domain names without judicial process, whether for gambling sites, or alleged illegal file-sharing by sites, where the sites have been ruled, in court, to be legal in their native jurisdiction (Spain). Today, we have the proposal in one draft law in the US for the federal government to be able to issue lists of domains which should not resolve and for all US ISPs to blacklist those domains on their resolvers automatically.
The assertion which annoys this troll is that DNSSEC solves these problems. It does not.
A government which can force changes in handling does not need to attack the packets solely at the point in the federation of DNS where a query is issued. Bear in mind that these days, we have
NSEC3 [†] doing inline near-wire-speed signing of DNS responses from authoritative servers, so the performance is there. If a government wish to control the DNS for “example.com”, they merely need to issue mandates about the signing keys used for the root zone, and control the root resolvers which the ISPs use, then operate some almost-transparent proxy DNS servers, which claim to be authoritative and pass through most queries and responses.
The governmental agency controlling a given nation's DNS need to issue their own keys for the root zone. They then re-sign the anchor public keys for all the entries within the root, except those for “.com”, for which they issue their own signing key. After that, they transparently re-sign all public keys for domains within .com except for example.com, for which again they issue their own keys.
At this point, replacing the X.509 PKI anchors in DNS with their own certificates is trivial.
Congratulations, by moving to put all certificates in DNS, you've created a single point at which control may be taken and provided the incentive to spend the money on building the farms of servers dedicated to nation-state level DNS serving with signing.
If the attempt is to defend against rogue nation-states which hijack traffic to, eg, cnn.com, then you've just failed and made it even easier for them to do so.
-The Grumpy Troll
[†]: oops, NSEC3 is the fixed version of NSEC which uses pre-computed hashes, chaining the hashes, to avoid disclosure (RFC 5155) and is what folks are moving to; inline signing was RFC 4470 "Minimally Covering NSEC Records and DNSSEC On-line Signing"; sorry for any confusion.