It can not be used this way. Adam Langley explained why. It has to do with the way browsers work. If there are 4,392 trusted CAs today, DNSSEC will make it 4,393. In practice, DNSSEC strictly makes the CA system worse.
People involved in DNS standardization clearly believe this isn't the case, and that there's a spectrum of different ways DNSSEC will interact with the CA system. They also believed in Interdomain IP Multicast and SNMPv3. The track record of DNS standards people on browser technology is not good. In this case: I suggest taking AGL's word for it.
Thomas, I definitely defer to AGL when it comes to browser technology - and I've certainly read his "Not DANE" piece, but you'll note he did not entirely rule it out. He just said it may be "a long way out". Two comments:
> It can not be used this way.
Actually, it can be. There's a modified version of Firefox maintained by the team at the DNSSEC-Tools project called "Bloodhound" that does DNSSEC validation of every link and does DANE checks on TLS certs:
> If there are 4,392 trusted CAs today, DNSSEC will make it 4,393.
Hmmm... I guess I see that only if you were using modes 2 and 3 of DANE. If you are using 0 and 1 you are just using DANE as an additional check for the CA-issued CERT.
The value to me is that I am in control of the TLSA record in that I am publishing that in my own zone file on my own DNS servers. I can specify there precisely which TLS cert I want to use or which CA I want to be trusted for my domain.
My choice is then cryptographically signed via DNSSEC and bound into the global chain of trust via DS records going back up to the root of DNS.
People involved in DNS standardization clearly believe this isn't the case, and that there's a spectrum of different ways DNSSEC will interact with the CA system. They also believed in Interdomain IP Multicast and SNMPv3. The track record of DNS standards people on browser technology is not good. In this case: I suggest taking AGL's word for it.