> * Amazingly, contrary to everything you'd expect about "secure DNS", DNSSEC does not in fact secure DNS queries from your machine. Instead, it delegates securing DNS to DNSSEC-enabled resolver servers. For securing the actual queries your computer makes, your browser is on its own. There's a whole different protocol, TSIG, intended to address that problem.

The stub resolver (library that provides gethostbyname() and friends to your browser) can in fact verify the DNSSEC signatures itself:

> http://www.cricketondns.com/post.cfm/securing-dnssec-s-last-...

> In particular, stub resolvers can set the CD bit in a query. The CD (Checking Disabled) bit tells the recursive name server not to validate DNSSEC-signed data on behalf of the resolver, but to return the various DNSSEC resource record types, such as RRSIG and DNSKEY RRs, so that the resolver can perform the validation.

> But no common stub resolvers implement their own DNSSEC validation, so CD is rarely used.

I expect this will be fixed in rather short order once there's a reason to fix it (say, all the major zones are signed and there's a semi-standardized DNS-as-PKI record type). Actually, I see a 'libunbound-dev' in the debian repositories already, which looks like a validating DNS resolver library (along with unbound-host and a couple other associated packages). I'll have to go play with this...

I also see discussion from 2003 about this, regarding wheter "stub resolver" is an appropriate term for something smart enough to validate the signatures (but apparently no claims that the end-user resolver shouldn't set the CD bit, just what to call that resolver): http://www.ops.ietf.org/lists/namedroppers/namedroppers.2003...

> * DNSSEC has zero successful real-world deployments, and no existing integration with any TLS stack. DNSSEC obviously does nothing to secure your actual traffic; all it does is try to protect the name lookup. TLS protects both.

Kinda hard to have a "real-world deployment" without the root signed... that said, there are some signed zones and there is https://itar.iana.org/ .

The idea is to have a way to use DNS as your PKI rather than a horde of independent CAs. TLS would still be used and work about the same (I'm guessing the only difference would be to check cert hashes against a DNS record instead of checking the signatures against a list of CA signing certs, not a protocol change at all).

How can TLS between you and a server protect the DNS lookup you use to locate that server?

> * DNSSEC does nothing to address all the other intercepts, from ARP to BGP4, that real traffic has to contend with. Once you go from name to IP address (or "cert" in the fairytale world where DNSSEC has replaced the CAs), you're on your own. TLS addresses all of these issues except for CA configuration.

...which can be addressed by using DNSSEC as a PKI.

> * DNSSEC actually reduces the security of DNS in some ways: in order to authenticate "no such host", DNSSEC publishes a sort-of-encrypted list of all your hosts. There's a whole other standards group drama surrounding the proposals to resolve this problem (NSEC3, whitelies, etc).

Not relevant, and apparently sufficiently resolved that there's a timeline to have everything signed within a couple years.

> * DNSSEC fails badly compared to TLS. When keys inevitably get screwed up in TLS, you get a browser click-through. There is no API support to recover from a "gethostbyname()" failure caused by DNSSEC. This sounds like a reliability problem, but it's actually a security problem, in the same sense as "the little blue key icon isn't big enough" is a security problem for SSL. We just don't know what the exploit is, because nobody has designed the "solution" for this problem.

Huh? People don't care about their TLS keys getting screwed up, because people will just click through that screen (security problem!). If people can't even find your site when your keys are screwed up, you'll actually care about making sure your keys are right.

> * TLS has 15+ years of formal review (it is the most reviewed cryptosystem ever published). We still find things in it. DNSSEC has received nothing resembling the same scrutiny. It's ludicrous to believe we won't find horrible problems with it. You'd be asserting that a protocol co-designed by Paul Kocher will eventually fare worse than one designed by the IETF DNS working group. The IETF DNS working group would basically have to crush some of the smartest practical crypto people in the world.

...DNSSEC is not in any way supposed to replace TLS, that would make absolutely no sense. But it can replace the CA infrastructure, with the result of making TLS (as commonly used) more secure.

> In the '90s, we designed web security to assume that DNS was insecure. That was a smart decision. "Security" means different things to different people. It's a policy decision. The end-to-end argument strongly suggests that it's something that can't be baked into the lower parts of the stack. DNSSEC is a step backwards. I think you can already see the indications of the problems it will cause just by looking at the places it already falls down.

How can it fall down, when it hasn't been set up yet? And how can "I know that this data is not forged" possibly be a step backwards from "this data could very well be fake, it's been known to happen"?