Hacker News Reader

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.

I dislike a lot of what has happened with DNSSEC too and try to focus on other things since this seems to be a lost battle. I'm not sure I'm convinced it makes the Internet worse, but I'm certainly skeptical.

That said, one thing I believe you're wrong on is gethostbyname() which does have an error channel via h_errno. It's not pretty and more things need to be defined to correctly handle DNSSEC issues, but there is something there. I agree though, that we're unlikely to find a good transparent way to have this work right with old applications and that's a killer.

I don't share your enthusiasm about SSL/TLS fixing this problem. SSL/TLS has its own issues...

Virtually nothing uses h_errno. You still need to update pretty much every piece of socket code. You're right to point it out though; thanks!

Also, look at how subtle the code needs to be to handle failures with h_errno --- you have to call gethostbyname, check h_errno regardless of what it returns, and then read the hostent; and, unlike certificate checks, this has to happen in every single place you ever use a domain name.

Also, what do you do when h_errno says something is tainted? First, you need to distinguish between transient and permanent failures. Now you need UI for both. Which means you've added another state machine hop in your program in every place you look up names (note that most network programs, even when they're async, don't bother to design host lookup asynchronously) --- what was one function call is now three functions, everywhere you look up names.

Anyone who uses curl to do stuff on the web probably knows the flag to turn cert checking off. Curl and wget are somewhat unique in needing to care about validation. Observe that now every single program that does anything with the network, from "ping" through "ftp", now needs a flag and a sensible default for how to handle broken names.

Yeah, this just isn't going to work.

Yeah, it's pretty bad.

There used to be herror() but it appears to have been deprecated. An central error checking function in the standard library wouldn't be a terrible addition. Handling GUI stuff sensibly is going to be an even larger nightmare, but at least frameworks like Cocoa and Qt should be able to help do this right. There's a large bridge right now for GUI error reporting that should be handled more gracefully in a lot of cases, not just for DNSSEC, frameworks need a graphical perror() in general.

In any case, DNSSEC certainly makes this all a bit more trouble.

Oh hey and now make this all thread safe.

Yeah...

I agree with you at most points, just two things:

a) SSL is worth jack shit. It only tells me that some person paid some obscenely large sum of money to some company so that my address bar glows in green. CAs do a very bad job at verifying their customers. There have been valid certificates at pishing sites and valid certificates with fake data.

DNSSEC wont't fix that. But it will guarantee that when I type bankofamerica.com in my browser, I will land at bankofamerica.com, even if someone tries to hijack me.

b) We do need DNSSEC. Please go and watch Dan Kaminsky's talk about the ramifications of the DNS bug he publicized. Everything in the end falls back to DNS. Want a SSL cert? You will receive it per mail. Guess how the CAs mail server will find your company's mail server...

c) Please don't start with "secure the connection" instead of "secure the data". Even if I know that the line between my computer and my DNS server is secure, I can't trust my DNS server.

a) SSL is worth jack shit. It only tells me that some person paid some obscenely large sum of money to some company so that my address bar glows in green. CAs do a very bad job at verifying their customers. There have been valid certificates at pishing sites and valid certificates with fake data.

I agree here, except I think you meant to say that SSL certs are worth jack. And that's entirely true, as far as I know. SSL the protocol is probably more or less ok.

I disagree with you in that I don't trust the competence of the designers of DNSSEC. We may need something similar, but I doubt that DNSSEC as it exists today is it.

Anybody who tells you that "SSL the protocol is fine, just ignore the signatures" isn't qualified to have an opinion about the relative security of crypto protocols. Without certificates, SSL offers no security.

Sigh. Go reread, but here's a hint: the main problem with SSL certs is not their technical implementation.

I'm ruefully amused at your suggestion that I go look up Kaminsky's talk. Yeah, I'll get right on that.

Your comment overall makes very little sense. The problem you're alluding to --- the one that means "SSL is worth jack shit" --- is a user interface problem. It's a serious one, but not only does it not go away in a DNSSEC world, it actually gets far worse.

DNSSEC isn't a magic bullet that solves the logistical problems of verifying Internet identities. The market has been beating the crap out of mutual authentication for financial websites for over 15 years. The company with a real solution to that problem will make billions of dollars. DNSSEC isn't that; it's a bunch of guys on a mailing list arguing about the one piece of the stack that they've chosen to fixate on --- and the surprisingly bad solution that resulted from the process.

This isn't just my opinion, by the way. Read every working group post (like I did) and watch Vixie's tone as the protocol evolves from what TIS came up with to where it is now, when he starts saying, in effect, "anything, anything, let's just get something deployed!"

"Did you know that SSL/HTTPS in no way relies on a secure DNS today?"

That's really too bad. It should. DNSSEC can handle providing CERTS. Using these CERTS and DNSSEC to validate them (on top of the rest of SSL/TLS) would be a secure and free way for domain owners to provide a better security than provided by SSL/TLS as implemented today.

SSL/TLS requests can be man-in-the-middled by any one with access to any of the 150 or so root keys in your browser including for example the governments of Taiwan and China. If we used CERT DNS records, then not only would we not have to pay additional money to VeriSign etc to have a CERT, but there would only be twoish keys that would allow man-in-the-middle attacks (the root DNS zone and the .com DNS zone for example). That is a significant improvement.

Does anyone know if any of the browsers have plans to provide DNS CERT support?

I love the suggestion that there is in fact a free lunch for company authentication; that we can simply replace a (very crappy) vetting system with a vending machine protocol and all our authentication problems will go away.

As for the "150 root keys" issue: that is in fact a very good point. Remove the sketchy ones from your browser. Someone should publish a list --- "these ones are probably fine for people in the US to remove". Whoah. Look. I just solved that problem in 15 seconds, using the Firefox UI; it didn't even require an IETF working group to discuss it!

;)