.ORG Zone Signed With DNSSEC

lothos and several other readers let us know that the Public Interest Registry has announced the key-signing key to validate the signatures on the ORG zone. A few more details are on the PIR DNSSEC page. PC World interviewed PIR CEO Alexa Raad and writes: "On June 2, PIR will announce that it is signing the .org domain with NSEC3 and that it has begun testing DNSSEC with a handful of registrars using first fake and then real .org names. PIR plans to keep expanding its testing over the next few months until the registry is ready to support DNSSEC for all .org domain name operators. Raad says she expects full-blown DNSSEC deployment on the .org domain in 2010."

Comments

djb

[Gothmolly]

We need a 'djb' tag. Dan's been talking about, and working on this kind of thing for years.

Re:djb

[Anonymous Coward]

We need a 'djb' tag. Dan's been talking about, and working on this kind of thing for years.

If 'this kind of thing' means DNSCurve rather than DNSSEC then sure, you are dead on! But rather we can see that DNSCurve != DNSSEC. DJB is, as usual, thinking that his idea's are better than an entire consortium and I'm sure that we will see him continue to break RFC at his whim because he simply does not understand, he thinks that he is better than others or some magical being had tapped him on the shoulder. Maybe you should take a trip back in a TARDIS to last year?.

I know... I know, don't feed the trolls.

Re:djb

[Anonymous Coward]

lol... you're kidding, right?

Re:djb

[MikeBabcock]

Maybe you should actually read up on why Dan's right or wrong about DNSSEC and make a point instead of harping on about his attitude issues.

He may have a god complex, but he's rarely wrong, so you might want to prove him wrong before you assume you have the right to judge his attitude.

Re:djb

[Neanderthal Ninny]

Mike Babcock is correct. You need to read and understandwhat Dan Bernstien says about DNSSEC before going this.
I'm using djbdns on my domain with .org and I need to find out what to do now. I wish to keep djbdns with this going on hopefully with a few (or more) patches to djbdns. A whole new world for me.

Re:djb

[Anonymous Coward]

you don't need to do anything if you don't want to, dnssec is fully backwards compatible. But of course you won't get its protection then.

Assumes a centralized DNS system

[BadAnalogyGuy]

If you believe that the U.S. will control the DNS system in perpetuity, then this seems like a fine idea.

Re:Assumes a centralized DNS system

[Anonymous Coward]

It doesn't assume a centralized DNS system any more than DNS does so itself.

Re:Assumes a centralized DNS system

[Anonymous Coward]

The idea that a DNS could be "poisoned" automatically assumes that there will never be any serious disagreement among DNS providers. This, while perhaps not being "centralized", is at least based on the idea that there is an objective true DNS database.

Re:Assumes a centralized DNS system

[Anonymous Coward]

The DNS can be "forked" by installing and using different root servers and DNSSEC doesn't change that. The alternative root servers simply have to sign all their records with the key of the alternative root and users have to replace the official public root key with the public key of the alternative root in their resolver configurations.

Re:Assumes a centralized DNS system

[morgan_greywolf]

DNS is a centralized system, no matter how you look at it. It may be politically correct for the entire population of Europe to bash the U.S. these days, but my response is this: if you think you can do better, go for it.

Re:Assumes a centralized DNS system

[Anonymous Coward]

That is a dangerous confrontation because much on the internet relies on an unambiguous view of the domain namespace. There is no technical reason why Europe (or Asia for that matter) couldn't establish an alternative root tomorrow. It would be better for the net as a whole to solve the conflict amicably, but if the US sticks to this "bring it on" attitude, we might well see a DNS split.

Re:Assumes a centralized DNS system

[Anonymous Coward]

And those that know howto properly use DNSSEC will find those to be invalid. This is not a self signed ``just accept it'' certificate.
You should probably read up on the idea a bit: https://dlv.isc.org/about/background

Re:Assumes a centralized DNS system

[morgan_greywolf]

I don't think it will happen for the very same reasons you state.

If it comes down to it, the only real way I see to fix this is whole mess amicably is to replace DNS with something that isn't centralized.

Re:Assumes a centralized DNS system

[Anonymous Coward]

The public root key is like the certificates which are installed in your browser: Unlike the keys of delegated zones, it forms a direct trust relationship, independent of further signatures, so it is indeed much like a self-signed certificate.

An alternative root can establish a completely separate namespace or it can integrate with the "official" DNS namespace and modify it by delegating certain names differently. There is no provision in DNSSEC which allows zones to reject delegations from "unauthorized" higher level zones. Authorization is strictly top-down.

Re:Assumes a centralized DNS system

[collinstocks]

I completely agree that we need something not centralized. In fact, I'm actually in the planning stages of an entire decentralized system to possibly replace the web. I know, I know...ambitious goals. But I am convinced that the concept could work.

The idea is essentially to create a decentralized web of trust, and have nodes on the network find each other by asking other nodes. One of the advantages is that it abstracts the underlying IP addresses that are used to identify network devices into something that can be extensible once IP addresses become infeasible (for example, in mobile devices whose subnets keep changing).

Re:Assumes a centralized DNS system

[morgan_greywolf]

Exactly what my thoughts were when I said "decentralized". I, too, have had a similar idea for a while, but I've not put any real effort into a workable implementation.

If I were to implement such a system, I'm thinking that I would start with some of the P2P protocols out there; perhaps BitTorrent is a good start.

Re:Assumes a centralized DNS system

[vivaoporto]

Although in a smaller scale, it already happened once: The Great IRC split. Once a single more or less decentralized network (just like the web now), disagreements on the policies lead to a transatlantic split. Hope that never happens on the WWW.

Re:Assumes a centralized DNS system

[Anonymous Coward]

I think there is a simpler solution: You have to ask yourself what the reason for the contention about the DNS root key is.

The purpose of the root key is to sign the records for which the root servers are authoritative, i.e. the delegation records for the top level domains (.com, .org, country code TLDs, ...). This protects against an attacker spoofing replies from the root servers and replacing records. Such an attack could be used to redirect queries for domains under certain TLDs to a different nameserver. With signed records and validating resolvers, the only entity which still has the ability to redirect queries is the one in control of the private root key. This creates an imbalance: The USA (as the holder of the private root key) could create signed records which change the delegation of the .cn TLD and use these records to subvert domain name resolution for .cn domains. China could not do the same to .com or other TLDs.

As users of the internet, our interest is that nobody has that ability, not that that ability is controlled by the US, the EU, the UN or any other committee. Instead of decentralizing the DNS root, why don't we simply allow anyone to sign the TLD delegation records and enable validating resolvers to request a selection of signatures of the resolver's choosing? If you as a user expect that the US and the EU could collude to subvert some other country's DNS records, ask for US and Chinese signatures.

Re:Assumes a centralized DNS system

[QuantumRiff]

If you were a real geek, you would just memorize the proper IPv6 addresses..

Re:Assumes a centralized DNS system

[Kjella]

I don't think it will happen for the very same reasons you state.

It's not as difficult as you think:
1. Start a new root
2. Root has your domains, but redirects all old domains to the US-controlled system
3. Require ISPs to point to the new root (it's the government, make it tue law)
4. Set a grace period for old domains to register with you
5. Make the cybersquatting reesolution process hell if you don't use the grace period
6. Turn off the lights on the old domains, alias them to the new ones

So you own google.com, EU starts with .comx - better register it or some porn site will take over google.comx until you can get it back. Repeat BS process a few times like the digital TV conversions by offering extensions and saying this time we're REALLY doing it. When you have enough on board, turn off the lights on the old .com, have it resolve same as .comx site. No "black net" sudden transition.

Re:Assumes a centralized DNS system

[CarpetShark]

It may be politically correct for the entire population of Europe to bash the U.S. these days

Ermm.. with all due respect, the US administration started it.

Re:Assumes a centralized DNS system

[morgan_greywolf]

You forgot:

7. ICANN tells the new root to piss off and refuses to point the 'real' roots at it.

Re:Assumes a centralized DNS system

[collinstocks]

I was thinking of starting with the BitTorrent protocol, but I would have to add so many things to it that it would be unrecognizable. I think that starting a ground-up implementation with extensibility in mind might be a better idea. However, part of what I want to do is make it possible to have multiple backends for the lowest software level transportation of data, and for that I could write an extension to allow bittorrent to be the protocol used there.

I'm not sure why I was modded funny...I'm actually planning this out. It'll be a while before I actually have the time to implement it, but I am planning it.

Re:Assumes a centralized DNS system

[nmx]

Your analogy is flawed. IRC is nothing like the web. As you said, IRC is a decentralized network. There are connections between the servers. "The web" doesn't exist - it's just a bunch of servers that have no connection to each other. The IRC split just referred to other people starting their own IRC networks. Maybe you meant to compare IRC to DNS, which is a giant network of sorts. I think a DNS split is very unlikely, though. There's little benefit to having a single giant IRC network, but obvious benefit to having a single DNS network, without which the whole Internet basically gets fragmented, from a usability standpoint.

Re:Assumes a centralized DNS system

[MikeBabcock]

It would be even easier to do as I've mentioned before and offer domain signing services through trust agencies much the same way we do current browser certificates.

That way we have both the efficiency of a hierarchy and the stability of a non-centralized repository.

(yes I'm aware I didn't completely flesh out the idea this time ... I'm sure you can come up with something similar to what's in my mind if you think about it)

Re:Assumes a centralized DNS system

[collinstocks]

The problem with trust agencies is that they are centralized because all users must be certain that they have the correct public key for each and every agency. Just because there are multiple points does not mean that it is totally decentralized if all users must know about all agencies in order for the system to work.

Furthermore, there is the problem of trusting the "trust" companies. How can you be absolutely certain that the public key you hold is actually the public key belonging to the trust company? What key distribution techniques can be used in this case, keeping in mind that before you have the public key of the trust company, you have no way of knowing that it is actually them. If you think about it, it becomes clear that this is circular unless you have a single trusted source that everybody knows about (such as a government) which has the ability to bring down wrath upon anyone who tries to forge their own certificates.

The only way that you could be certain that the public key you hold actually belongs to the trust company is to retrieve it from them through a secure channel (i.e. sneakernet) where you can verify that it is actually theirs (by visiting their physical establishment as described by whatever agency that deemed them a trustworthy).

I am not advocating a centralized system. However, I am saying that a partially decentralized system is not actually provably secure for most people (see sneakernet counterexample above).

The true solution is to use something that mimics the way trust forms in a social community. Essentially, this works on the basis of reputation as determined by other users/devices/nodes on the network. The basis for it is that in the real world, trust doesn't work because untrustworthy parties are prosecuted; instead, real people base their trust on a "web of trust" -- a small-world network of people who trust each other at different levels based on past experience.

This is the difference between the current system of "trusted networks" (be honest or be criminally prosecuted) and social networks (be honest or you will no longer be trusted). The latter, however, requires some sort of intelligent logic, which I am still working on.

Re:Assumes a centralized DNS system

[ronabop]

China, is that you?

Re:Assumes a centralized DNS system

[Anonymous Coward]

You do not understand how DNS works. There is no centralized service pointing to the "real" roots. ICANN can't do a thing.

The ones pointing to the root is the ISPs. That was taken care of in pt. 3.

Re:Assumes a centralized DNS system

[MikeBabcock]

Hopefully you've looked over dnscurve

DNSSEC and domains and subdomains?

[Midnight Thunder]

So what does this mean for domains in the .org realm? Should people be adding DNSSEC to their own domains, and if so what sort of cost should we expect? Also, how does software on a PC validate that a domain is signed?

Re:DNSSEC and domains and subdomains?

[Anonymous Coward]

DNSSEC is a public key system in which each nameserver signs the records for which it is authoritative. Encryption is not used, to avoid a per-request overhead. A resolver can validate signed records because the public keys of delegated zones are records delivered by higher level servers, starting at the root servers. The .org domain delivers signed records now, so nobody can fraudulently claim to be authoritative for .org in communications with a validating resolver anymore. They can still claim to be authoritative for your domain under .org, unless you also sign your records and add the public key to the delegation records for your domain.

Re:DNSSEC and domains and subdomains?

[QuantumRiff]

Which, btw, will eventually eliminate one of the most profitable parts of the the SSL merchants portfolio, proving that you are who you say you are. Even without a Cert, you will know that you are at YOUR bank's website, because you will be able to walk up the tree with signed records..

Re:DNSSEC and domains and subdomains?

[Timmmm]

What about man in the middle attacks? E.g. over insecure wifi. You still need SSL I think.

Re:DNSSEC and domains and subdomains?

[Kadin2048]

You do, but the encryption part is relatively easy; it's the authentication that's hard. Right now, Verisign et al charge megabucks for "Extended Validation" certificates (mostly to banks, insurance companies, etc.) whose only advantage over a regular "el cheapo" SSL cert is the supposed additional validation.

Securing DNS would let you use it for validation, rather than the SSL certificate trust chain. So the E.V. certs would really not be necessary anymore.

Actually I think securing DNS would make MITMs a lot harder (although I wouldn't go so far as to say 'impossible') because most current MITM attacks rely on DNS poisoning.

Re:DNSSEC and domains and subdomains?

[Anonymous Coward]

There is currently no standard for this, but with validated DNS records, the browser could get the public key of the web site through DNS. That would make the SSL certificate hierarchy redundant. You would still use SSL, but the web server could identify itself as the legitimate server for the domain through signed DNS records instead of signed certificates.

Theoretically SSL certificates are supposed to prove more than just control over a domain or web server, but in practice the CA system has devolved into proving just that. Now you need "extended validation" certificates, which are more expensive, to prove that someone actually verified your identity (if you believe that kind of assurances...).

So yes, QuantumRiff is correct: DNSSEC has the potential to provide a substitute for simple SSL certificates and self signed certificates in one go.

Re:DNSSEC and domains and subdomains?

[Nevyn]

Even without a Cert, you will know that you are at YOUR bank's website, because you will be able to walk up the tree with signed records.

No, you would know that you are at "yourbank.com" you wouldn't know that it's "YOUR bank's website" ... which is the problem the new super certs. are trying to address.

Re:DNSSEC and domains and subdomains?

[geniusj]

DNS poisoning is not the only way to hijack a website. It is also possible to do such things via unauthorized BGP advertisements to an insecure carrier. If you do that, the DNS is irrelevant, you've just hijacked the IP according to some portion of the internet.

Re:DNSSEC and domains and subdomains?

[MikeBabcock]

... and a trust network with ad-hoc IPSEC would be a much more valuable feature for the Internet than DNSSEC IMHO as it would completely eliminate these problems.

Re:DNSSEC and domains and subdomains?

[complete loony]

Yeah, but we can publish public keys in DNS for use in end to end encryption, or authentication. If the chain of trust starts at the root of DNS and flows down all the way to the connection to the web server, how are you planning to spoof it?

Yes but how do I implement it...

[Anonymous Coward]

Every time some organisation wants to push some new system or regime they drop into hype overdrive. There are emails, announcements, articles, PDFs a plenty, but try as you might, the actual information you need to enable you to implement stays carefully hidden from view. This isn't about security; if it was the technical details of configuration and operation would be at the top of the list of files to view. It is about some organisation seeking praise and glory for doing something or other.

Re:Yes but how do I implement it...

[Tony Hoyle]

It's pretty hard to implement right now.. a bunch of shell scripts and editing with vi, and even then I've never got it to work. One key thing is it's incompatible with dynamic DNS so you can only use it on static zones.

The other thing is for it to work it has to be signed by a parent zone.. or in other words, more excuses for verisign to charge $$$ per year for doing almost nothing. This, of course, is why it's being pushed so much.. there's money in it.

Re:Yes but how do I implement it...

[Anonymous Coward]

The .org zone is signed now. That means that the records which delegate authority of your domain to your domain name server are signed. Verisign's work is done, so to speak. All that is left is for you to sign your records as well and add your public key to the delegation records of your zone. That's just another record with no additional authentication requirements, so it would come as a big surprise if your registrar charged you extra for that. Of course, with people like you equating cryptography to $$$, they might go for it just because their customers expect to pay.

Re:Yes but how do I implement it...

[Anonymous Coward]

maybt it's cause you still use vi...

Re:Yes but how do I implement it...

[Anonymous Coward]

there's money in it.

The signing keys for your .org domain are simply added as DNS records to the name server next up the tree from you.

If your DNS provider is charging you per A record, you definitely need to switch away from them and to *anyone* else. Then you won't be charged to add more records to your zone.

I have never seen a DNS provider charge per A record before thou.. so I suspect you are just misinformed about exactly what money is involved (aka none), or you are being ripped off really bad.

For under $20/mo you can get a shell account somewhere and setup BIND9 yourself and host your domain there.
Then there will be no further cost, and DNS is really something you need anyway.

So lesson is, stop paying per record! Leave your current provider that is doing that, and go to literally any other DNS host. Charging you more for two extra little signing key records is ridiculous!

In addition, it is not incompatible with dynamic records at all. You should double and tripple check your name server docs, or switch to a more sane name server line BIND9 or djbdns. Both of those servers support dnssec correctly, and you won't have to mess with shell scripts or any crap.

If you have a dynamic record, say home.example.org which is updated dynamically when your home DHCP lease changes.. You will have the signing keys for example.org posted up with the .org top level, and at that point you are done. home.example.org's A record will only be verified signed by your name server for example.org which will have the keys stored at .org. Your home dyndns setup will need zero changes.

Re:Yes but how do I implement it...

[kv9]

Yes but how do I implement it...

fast and easy.

Re:Yes but how do I implement it...

[marka63]

It's pretty hard to implement right now.. a bunch of shell scripts and editing with vi, and even then I've never got it to work. One key thing is it's incompatible with dynamic DNS so you can only use it on static zones.

It most definitely not incompatible with dynamic zones. I've got plenty of signed dynamic zones and have for years.

The other thing is for it to work it has to be signed by a parent zone.. or in other words, more excuses for verisign to charge $$$ per year for doing almost nothing. This, of course, is why it's being pushed so much.. there's money in it.

Yet another conspiracy theorist. I know this is /., but really do some research and find out how much the existing TLD's are charging. $0.

O.o

[Anonymous Coward]

using first fake and than real .org names.

o.O - A small typo I know, but it's of the super irritating variety.

Re:O.o

[fracai]

Same here. For me, it's a robot killer.

Re:O.o

[Anonymous Coward]

And a thread title that is some sort of emote isn't irritating ?

Americans

[dandart]

Americans don't own the Internet! They just own all the Internet names! It's a big difference!

Re:Americans

[FreakyGreenLeaky]

Yes, they do. They own you too, beeatch.

/does grotch-grabbing hip-hop dance-thingy...

Re:Americans

[dandart]

I live in England, you insensitive clod!

Re:Americans

[JamesTRexx]

I live in England

Like he said, they own you... :-P

Re:Americans

[dandart]

Damn your futile accusations. We own them,

Re:Americans

[FreakyGreenLeaky]

no. no. You need to embrace The Truth, you'll feel better, trust me.

The USAians kicked yer lilly white bums, then the RSAians kicked yer lilly white bums too :D

It follows, therefore, that you are owned, beeatches!

Silly colonialist can't get the message. btw, I'm a tri-breed Scot/German/Dutch, so therefore I own you all.

Say, "who's your daddy?"

Re:Americans

[dandart]

Damn you, just you. We have the Empire and the Commonwealth, and plus I am the Emperor.

Re:Americans

[FreakyGreenLeaky]

Emperor with no clothes on, another reason yer my beeatch. There, pick up that bar of soap for me, heh-heh.

I wouldn't brag too loudly about the Commonwealth btw - last I checked there were a bunch of banana republics as members (an' zim was only recently kicked out - or were they? can't remember).

The only respectable commonwealth member, I believe, is oz. However, they speak funny and have too many flies, so they're owned too. Also, they're american wannabees: they say 'truck' instead of 'lorry'. Dummies.

So, I repeat, say "who's your daddy?"

Re:Americans

[Anonymous Coward]

I wouldn't brag too loudly about the Commonwealth btw - last I checked there were a bunch of banana republics as members (an' zim was only recently kicked out - or were they? can't remember).

Commonwealth, banana republic... Massachusetts?

What should domain owners do?

[GlobalEcho]

As the owner of a .org domain (used for a few websites and email) is there anything I ought to be doing based on this? I'm registered at Dotster, hosted elsewhere (Dreamhost).

Re:What should domain owners do?

[modi123]

As a .ORG domain owner (renter?) I second this question. Is there anything I need to be worried about or need to address?

Re:What should domain owners do?

[Anonymous Coward]

Yes. You must change your config at Dotster, and it must be exactly correct or people will soon not be able to connect to your domain via DNS.

If you do not know how to correctly change your domain info, please enter your DNS server login credentials here, and someone will fix your records for you shortly afterwards. In fact, this is the suggested way to fix this problem, by leaving your login info here and having a qualified person do the work for you pro bono.

Re:What should domain owners do?

[Lennie]

If your provider which handles the domain doesn't support DNSSEC, nothing will change. If they do do it, they'll probably do it for you. Because it's quiet complicated to get right and needs lots of automatic rekeying.

Re:What should domain owners do?

[HTH NE1]

Because it's quiet complicated to get right and needs lots of automatic rekeying.

Quite quiet. Almost silently complicated.

Re:What should domain owners do?

[Slashcrap]

I'm registered at Dotster, hosted elsewhere (Dreamhost).

I wouldn't put too much effort into it. Dreamhost will probably have accidentally deleted your site by the time you finish reading this anyway.

Re:What should domain owners do?

[Lennie]

Sorry for not being a native english speaker and thanks for the pointer. :-)

Re:What should domain owners do?

[HTH NE1]

Sorry for not being a native english speaker and thanks for the pointer. :-)

You'd be surprised how many native English speakers get it wrong. I'm even surprised how many native English speakers can't even speak properly. (When is Meadow Guild Solid coming out again?)

There's even this homophone list that has questionable entries like "sort, sought", "talk, torque", "tuba, tuber", and "pawn, porn", which to me sound nothing alike. What dialect of English pronounces those pairs of words the same? Certainly not a proper one.

"And when all the programs on all the channels actually were made by actors with cleft palates speaking lines by dyslexic writers and filmed by blind cameramen—instead of merely seeming like that—it somehow made the whole thing more worthwhile." -- Douglas Adams

Why DNSSEC?

[Moxon]

I've read about what DNSSEC does, but I haven't found is an actual reason why anyone should care. Is there one?

Seems to me it kinda-sorta solves a few non-problems, and any actual problems it might touch upon have been solved better by SSL certificates years ago. Is it just that ISC is envious of the SSL cert sellers, and want to create a new action they can have the largest piece of?

Re:Why DNSSEC?

[Anonymous Coward]

I agree - I did a research paper, and all of the past incidents that DNSSEC says it could've prevented, were caused because someone screwed something else up anyway. It's a bandaid on a bullet-wound.

Re:Why DNSSEC?

[cybaz]

Not all sites will want to use https/certificates. Non-https sites will want to make sure that customers are properly directed to their authentic site.

Re:Why DNSSEC?

[Todd Knarr]

Basically, DNSSEC lets your computer verify that the DNS responses it's getting back are really identical to what's in the authoritative zone. If someone injects bogus DNS records into your nameserver or floods you with bogus responses to your query hoping to get one of them accepted, they won't have the private key for that domain so they won't be able to create a valid signature for their records and your DNS client will reject the bogus records.

That, BTW, is why DNSSEC has to start at the top to work. If I have DNSSEC for silverglass.org but not at the org level, then someone can inject bogus key records at the org level that'll let them successfully forge signatures for silverglass.org. To prevent that the root nameservers have to sign the org data (including the keys for domains in .org) so I can verify them using local copies of the root public keys (similar to the way we have local copies of the root nameserver names/addresses).

Re:Why DNSSEC?

[Kadin2048]

> and any actual problems it might touch upon have been solved better by SSL certificates years ago.

A lot of what SSL does, or tries to do, would not be necessary if the DNS was secure and not as open to spoofing. DNSSEC fixes some of the biggest flaws and will hopefully reduce the dependence on SSL and the enormous economic rents charged by Verisign et al for certificates.

Re:Why DNSSEC?

[Lennie]

This isn't quiet true, what is currently implemented is, that recursive nameservers ('caching nameserver' at your ISP, the nameserver IP-addresses you possible get through DHCP, etc.) can verify things. But in reality most probably don't. There isn't a desktop in sight which actually does do verifying, AFAIK.

Re:Why DNSSEC?

[Todd Knarr]

Well, anything running the major nameserver software probably can verify DNSSEC signatures. Given the way most ISPs have things set up, your local machine shouldn't need to verify if the ISP's nameservers are verifying. The only machines that could inject bogus data directly into your local machine would be on the local segment of your ISP's network, whereas the major DNS injection threat today is from outside the ISP's local network. And without DNSSEC things can't verify even if they want to, which is a good argument for having it there so people who want to protect themselves can.

Re:Why DNSSEC?

[jhutkd]

DNSSEC address issues that include the Kaminsky cache poisoning attack from last summer. The idea of DNSSEC is that when you get a DNS record back, you can use crypto to verify that it the actual record (such as the IP address(es) for a web site) served by a domain.

If you're seriously interested in _why_ someone should care about DNSSEC, check out this 4 minute tech-talk:
      http://www.youtube.com/watch?v=Yt-oJTj0j0o

Re:Why DNSSEC?

[MikeBabcock]

If you actually trust your ISP as much as you imply that we should in that paragraph, you're in trouble.

I run my own caching DNS service on my computer to resolve addresses (because I can) and get much better performance and security out of it than trusting my ISP. Either way, I can't know if a DNS address was signed or not when I'm actually using the results (whether on the web, through SSH or when MSN logs into the Microsoft servers), and that's a problem for adoption.

If the user can't tell that the records they're using are trusted or not, there's very little incentive for the records to be properly signed in the first place.

Re:Why DNSSEC?

[Todd Knarr]

Well, as a matter of fact I don't trust my ISP's DNS servers. That's why my gateway box runs a copy of BIND going directly to the root nameservers, it's configured to use and verify DNSSEC if present (currently it can only verify my internal zones), and firewall's configured to block access to DNS except via the gateway box.

Note that users aren't supposed to need to verify the DNS records. The idea is that the nameserver the user's querying verifies the incoming responses and simply discards any whose DNSSEC signatures don't verify. The only people who have to worry about ever even seeing an unverified response would be people running nameservers themselves, and they're presumed to either have configured their software to do the verification or to not care about bogus records.

Re:Why DNSSEC?

[Anonymous Coward]

Windows 7 includes a validating resolver.

Re:Why DNSSEC?

[Anonymous Coward]

A lot of what SSL does, or tries to do, would not be necessary if the DNS was secure and not as open to spoofing.

SSL is still very necessary even if DNSSEC gets put in place and working properly. The DNS system is just a means for turning a name into an IP. It's true that it does present one attack vector in that the attacker can return his or her own IP when resolving the name, but even if the user can be absolutely sure that the IP they got back from the DNS query is correct, there's still the matter of routing traffic through to that IP.

Executing a MitM attack is probably harder since you'd either need to control the networks through which the user is connecting (either by owning them or hacking them), but it's still possible. And it's the network operators that make SSL a necessity. The Chinese government could force ISPs to route traffic to sites used by political dissidents through their own proxy without anyone knowing. Or a US network operator could setup a proxy for a sites that facilitate file sharing. There's any number of reasons why a legitimate network operator with full control over routing to a give IP might want to be the "man in the middle" of a network connection.

SSL solves this by giving the user's browser the ability to tell the user that the site they got a response from sent them a certificate that they could only have purchased from one of the know CAs. With SSL, a network operator would now have to collude with one of the CAs to generate legitimate certificates in order to intercept traffic. The problem solved by SSL quite different from the problem that DNSSEC would solve.

Re:Why DNSSEC?

[marka63]

Actually DNSSEC solves the problem of assuring the data associated with the domain name is that which was entered. DNSSEC can sign CERT records which match the CERTS used by your http server. It just requires the browsers to accept this trust path in addition to the traditional trust path using CA's.

DNSSEC actually does a much better job of this association than any CA can because the CA is outside of the normal trust path associated with DNS delgations.

Re:Why DNSSEC?

[marka63]

DNSSEC doesn't have to start at the top. It's just easier if you do so as
you reduce the number of trust anchors you need to manage.

For those of you waiting for the root to be signed, this will happen this year (2009).

Re:Why DNSSEC?

[Moxon]

He explains why DNSSEC fixes one aspect of MiTM attacks, but he fails to mention any reason to prefer it over SSL certificates, or even in addition to SSL certificates. The example he uses (login / banking information) isn't something you'd want to be passing around unencrypted, anyway..

Re:Why DNSSEC?

[jhutkd]

Rather than start w/ his example, consider the attacks seen after the Kaminsky announcement: MX records were being forged. Now I can poison an ISP's caches w/ the wrong records for email of any site and all of your email will go through me. Do you ever send anything interesting over email? ;) This was seen in the wild.

WRT the video, at Blackhat there was a presentation demoing the creation of forged SSL certs using weak CAs. Now, if DNS hands you an IP for a domain that really belongs to a MitM. Now your browser _thinks_ that it is talking to the real domain and just needs a cert that matches. Poof, wormhole attack.

Really, the problem here is your browser/OS comes bundled w/ a bunch of very poorly maintained root CAs that you should "trust". Who knows who many of them are, but if your browser is happy with a cert from any of them for any website, you get a nice false sense of security. DNSSEC doesn't address this specific problem. Rather, it makes it perfectly clear what DNS data can be verified. If you go to a rogue website, that is a higher level problem, but at least with DNSSEC you _know_ when you're at a rogue web site. SSL conflates too many things and can be dangerous if misunderstood.

Re:Why DNSSEC?

[Burz]

DNSSEC address issues that include the Kaminsky cache poisoning attack from last summer. The idea of DNSSEC is that when you get a DNS record back, you can use crypto to verify that it the actual record (such as the IP address(es) for a web site) served by a domain.

Pardon me, but that is dumb. Almost all of the overhead in asymmetric crypto (used by DNSSEC and SSL) is in the initial or verification stages. SSL already does that job but gives us actual encryption and privacy of our data for very few extra CPU cycles.

Show me where DNSSEC verification saves resources over using SSL and I just might reconsider my position that DNSSEC is a solution looking for a problem.

Re:Why DNSSEC?

[Burz]

Rather than start w/ his example, consider the attacks seen after the Kaminsky announcement: MX records were being forged. Now I can poison an ISP's caches w/ the wrong records for email of any site and all of your email will go through me.

Hold on there. Are you suggesting that a worthwhile email service wouldn't use SSL? What if these crummy services that were attacked also fail to use DNSSEC?

WRT the video, at Blackhat there was a presentation [greyhatindia.com] demoing the creation of forged SSL certs using weak CAs.

Ah, so that's it. Only the central bureaucrat can be trusted to run everything ship-shape.

I feel so much safer......

Re:Why DNSSEC?

[Schraegstrichpunkt]

...and any actual problems it might touch upon have been solved better by SSL certificates years ago.

Wow. Is DNSSEC that bad? It's hard for me to imagine any serious crypto protocol being worse than SSL certificates.

Try reading this.

It's correct

[GameboyRMH]

The testing of an improved DNS system has a positive connotation.

http://www.bbspot.com/News/2009/05/five-farther-grammar-rules-you-may-not-have-known.html

Grotch?

[GameboyRMH]

You have a gross or unsavory crotch?

http://www.urbandictionary.com/define.php?term=Grotch