Root DNS Zone Now DNSSEC Signed(isc.org)
isc.org
Root DNS Zone Now DNSSEC Signed
http://www.isc.org/press-release/isc-praises-momentous-step-forward-securing-domain-name-system
27 comments
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.
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.
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.
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...
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.
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.
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.
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.
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.
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!"
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!"
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.
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.
[deleted]
I'm going to continue ignoring DNSSEC until I see it affect clients in a meaningful way. Until then I think there is other things my users would prefer I spent my time on.
The entire point of this story is that until this week your clients couldn't have used it even if they wanted to and that changed.
I'm not saying you have to go running off and caring about DNSSEC now, but the kneejerk "omg it's not deployed" argument really isn't helpful or insightful attached to a story about how it just finished getting deployed for real on the roots finally after years of waiting.
I'm not saying you have to go running off and caring about DNSSEC now, but the kneejerk "omg it's not deployed" argument really isn't helpful or insightful attached to a story about how it just finished getting deployed for real on the roots finally after years of waiting.
Your reading of my post as "omg it's not deployed" is an unwarranted exaggeration. I merely stated that for me, someone who maintains a from the wire-up DNS implementation, this baby-step doesn't change anything practical — which is something you've agreed with.
EDIT:
It goes without saying but I'll state it anyway, this cascade of down-votes is not the reaction I'd expect for making what I consider to be a pretty innocuous comment about something that potentially affects the priorities of my startup.
EDIT:
It goes without saying but I'll state it anyway, this cascade of down-votes is not the reaction I'd expect for making what I consider to be a pretty innocuous comment about something that potentially affects the priorities of my startup.
It goes without saying but I'll state it anyway, this
cascade of down-votes is not the reaction I'd expect for
making what I consider to be a pretty innocuous comment
about something that potentially affects the priorities of
my startup
If you insist on not caring, do so quietly. Some people around here are trying to fix things, or break them, which hopefully will result in better systems. In any case, you appear to be doing neither.
(As a side note, your assertion that I agree that this doesn't change anything practical is false, as of yesterday people can resolve domains over DNSSEC, that wasn't true last week. I consider this a practical change. I'm not a big fan of DNSSEC as a protocol, but this is a big deal(tm).)
as of yesterday people can resolve domains over DNSSEC
People can resolve the root over DNSSEC. This is a milestone, but it's one to be followed by many, many more before it affects clients.
People can resolve the root over DNSSEC. This is a milestone, but it's one to be followed by many, many more before it affects clients.
No, some TLDs have already signed their zones. Some people are able to use DNSSEC today.
isc.org appears to be using it already, for instance.
Edit:
isc.org appears to be using it already, for instance.
Edit:
$ whois isc.org | grep DNSSEC
DNSSEC:SignedRegarding TLDs, you're again intimating that I have said something that I have not said.
I do not dispute that some people are able to use DNSSEC and this does not belie my original comment.
I do not dispute that some people are able to use DNSSEC and this does not belie my original comment.
Last week: No one could use DNSSEC. No one did. No one was affected.
Today: Many people can use DNSSEC. Some actually are. Some clients are affected. (Just obviously not yours, since you remain completely uncaring about the subject.)
I don't see how it could be any clearer.
Today: Many people can use DNSSEC. Some actually are. Some clients are affected. (Just obviously not yours, since you remain completely uncaring about the subject.)
I don't see how it could be any clearer.
Your assessment of what constitutes "many people" and mine clearly differs.
You are quite right that my clients are unaffected. I like most of the world run a mix of Windows and OS X which like the software that runs on top of them, are not DNSSEC aware (with few exceptions).
Clearly I do care about the subject and I'm not sure why you keep stating that I do not. There is a difference between ignoring a technology until it's useful and ignoring it full-stop.
EDIT: Edited for brevity.
You are quite right that my clients are unaffected. I like most of the world run a mix of Windows and OS X which like the software that runs on top of them, are not DNSSEC aware (with few exceptions).
Clearly I do care about the subject and I'm not sure why you keep stating that I do not. There is a difference between ignoring a technology until it's useful and ignoring it full-stop.
EDIT: Edited for brevity.
You're messing with people's hope.
People want a story about how the Internet is getting a cool new security capability.
They especially want that story to come at the expense of Verisign and the SSL CA's.
Expect downvotes.
People want a story about how the Internet is getting a cool new security capability.
They especially want that story to come at the expense of Verisign and the SSL CA's.
Expect downvotes.
Did you know that they designed DNSSEC in a way that makes it difficult to not dump all your hostnames to the public, 'host -l' style? In order to provide a non-repudiable "no such host" message, they made DNS zones walkable. When people freaked out about that (justifiably so!), they modified the protocol so that names are hashed, password-file-style --- and are password-file-style crackable.
Did you know that because almost every piece of software that does name lookups uses "gethostbyname()", which provides no error channel, DNSSEC can't even give you a scary popup when a key expires or something is misconfigured? That unlike SSL --- which causes millions of such popups every day --- DNSSEC basically implies that either everything's configured 100% perfect or... that host doesn't exist?
Did you know that SSL/HTTPS in no way relies on a secure DNS today? That all that certificate signature stuff that people complain about boils down to a system designed to work even if the DNS is totally hostile and owned by attackers? And that the system has been attacked and refined and basically solid for something like 15 years?
Did you check out Dan Bernstein's presentation about using DNSSEC as a denial-of-service amplifier? I leave it as an exercise for you to find out how many megabytes of traffic you can get DNS servers to hurl at Twitter in response to just a few packets of your own.
DNSSEC is a debacle. It's been scrapped and redesigned (I believe) three times now, from the days in the 90s when it was a government project to the "whitelies" and "NSEC3" scramble that happened just a few years ago when they tried to deploy the "everyone gets a list of everyone else's hosts" design.
What's worse, we don't need it. DNS has been insecure for over 15 years, and DNS is not a primary attack vector on the Internet. When DNS is part of a malware attack, more often than not it's because the malware has reconfigured the victim host, which DNSSEC can't do anything about.
What's worse than that is that the bit we really could stand to address --- the insecure connections between end user computers and DNS servers --- could have been secured at far less cost and drama than the cache-to-authority problem the DNSSEC group bit off. But wasn't.
There seems to be some momentum behind finally getting DNSSEC deployed. I think it's actually bad for the Internet; that it will cause reliability problems, create a huge amount of work for server admins, not solve any real-world security problem, and create a false sense of security. But be that as it may, it appears to be coming.
Just make sure nobody gets your credit card for any kind of DNSSEC-y service. That's, I guess, my advice.