Comment by kijeda | Hacker News Reader

Comment by kijeda | Hacker News Reader

Parent Full thread

1. Place a resolver on your laptop. Many believe we are moving to a world where the DNS logic is on each host, because we've moved beyond the time where you need to offload the heavy lifting of DNS processing to some remote server. Perform iteration locally.

2. NSEC3 doesn't allow zone walking. DNSSEC entirely gives you the option as to whether or not to allow zone walking.

3. That is not an artifact of DNSSEC, that is an artifact of the fact software vendors haven't come to consensus on an approach on richening their DNS APIs. Arguably this is a chicken and the egg problem, which is why many have felt it was more important to get zones signed and then software vendors can come to a an improved approved they can test against deployed zones.

4. Many believe DNSSEC will enable SSL to move to a model where certificates are published in the DNS, rather than blessed by third party CAs. Imagine self publishing certificates in the DNS for free rather than paying for costly validation by a company like VeriSign? Once the DNS is secure it provides the same level of trust that SSL vendors provide (i.e. that the domain is registered to you)

But the great thing is, if you don't like DNSSEC, you don't have to use it. End of story. It was designed to allow the DNS to run as-is if you decide not to turn it on.

1. Nobody has a resolver on their laptop. Up until this very argument, the suggestion that people (for instance) stick djbdns dnscache on their laptops instead of using (say) OpenDNS resulted in a spew of FUD about straining the root servers. Either way, it's irrelevant; at the same time we roll out laptop DNS caches, let's also give everyone two factor authentication and a pony too.

2. You need to acquaint yourself with Dan Bernstein's presentation on NSEC3, but I think we can trust each other that we're not simply making things up. Like I said, NSEC3 --- the solution to zones being OVERTLY walkable --- creates a crackable "zone password file" that everyone can download.

3. The lack of UI for dealing with DNS failure is an artifact of the fact that the DNS was never meant to be secure, and so trying to layer an incredibly complicated security service model on it is a bad idea. Saying "that's up to the vendors to agree on" is, like the "sufficiently optimizing compiler", the very definition of hand-waving.

4. Those people who think that SSL CA's can be replaced by a vending machine built into the DNS are --- excuse the hyperbolic tone --- delusional. This suggestion not only doesn't solve the problem of how crappy vetting is for certificates, but actively amplifies it.

5. Wrong. If you are (for instance) a YC networking startup, you are going to pay through the nose in admin BS to deal with the hassles and failures created by this system which will cost billions of dollars across the board to deploy and which won't solve problems.

Also, for what it's worth: it's disingenuous to suggest that the DNSSEC working group "didn't make DNS zones walkable" --- NSEC3 is as hacky as it sounds because that's exactly what it is, a hack (and if you think that's a hack, read the whitelies proposals). Until the late appearance of NSEC3, not only were DNSSEC zones completely walkable, but many people on the working group argued vigorously that all zone contents on the Internet are effectively public information and that there was no valid reason that people on the Internet shouldn't be able to dump the contents of any secure zone.

This is roughly what you'd expect from a workgroup led in part by people who's zones consist of machines like "old-1994-dec-alpha.state.school.edu" and "ultra-5-with-sentimental-value.math.state.edu". The impedance mismatch between this kind of person and the people who maintain "backend1.staging4.apac.bank.com" appears to be part of the reason that DNSSEC is such a debacle.

Reply on news.ycombinator.com