.ORG Zone Signed With DNSSEC 89
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."
djb (Score:3, Informative)
We need a 'djb' tag. Dan's been talking about, and working on this kind of thing for years.
Re: (Score:1, Informative)
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 [dnscurve.org] rather than DNSSEC [ietf.org] 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 [wikipedia.org] to [wikia.com] last year [slashdot.org]?.
I know... I know, don't feed the
Re: (Score:3, Interesting)
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: (Score:2)
Mike Babcock is correct. You need to read and understandwhat Dan Bernstien says about DNSSEC before going this. .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.
I'm using djbdns on my domain with
Assumes a centralized DNS system (Score:3, Insightful)
If you believe that the U.S. will control the DNS system in perpetuity, then this seems like a fine idea.
Re: (Score:2, Informative)
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: (Score:1, Interesting)
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" h
Re:Assumes a centralized DNS system (Score:5, Insightful)
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 (Score:5, Insightful)
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: (Score:2, Insightful)
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: (Score:3, Funny)
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 tha
Re: (Score:1)
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: (Score:2)
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 p
Re: (Score:2)
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: (Score:2)
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? W
Re: (Score:2)
Hopefully you've looked over dnscurve [dnscurve.org]
Re: (Score:3, Funny)
Re: (Score:3, Interesting)
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 w
Re: (Score:1)
You forgot:
7. ICANN tells the new root to piss off and refuses to point the 'real' roots at it.
Re: (Score:1, Informative)
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: (Score:2)
Re:Assumes a centralized DNS system (Score:4, Insightful)
Re: (Score:2)
Re: (Score:2)
Ermm.. with all due respect, the US administration started it.
DNSSEC and domains and subdomains? (Score:4, Interesting)
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? (Score:5, Informative)
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: (Score:2)
Re: (Score:2)
What about man in the middle attacks? E.g. over insecure wifi. You still need SSL I think.
Re:DNSSEC and domains and subdomains? (Score:4, Informative)
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: (Score:3, Insightful)
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: (Score:2)
... 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: (Score:2)
Re: (Score:3, Interesting)
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.
Yes but how do I implement it... (Score:5, Interesting)
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: (Score:3, Informative)
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: (Score:3, Insightful)
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 $$$,
Re: (Score:1)
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.
Re:Yes but how do I implement it... (Score:4, Informative)
Yes but how do I implement it...
fast and easy. [isc.org]
O.o (Score:1, Funny)
using first fake and than real .org names.
o.O - A small typo I know, but it's of the super irritating variety.
Re: (Score:2)
Same here. For me, it's a robot killer.
It's correct (Score:2)
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 [bbspot.com]
Americans (Score:3, Funny)
Re: (Score:1)
Re: (Score:1)
Re: (Score:2)
Like he said, they own you...
Re: (Score:1)
Re: (Score:1)
The USAians kicked yer lilly white bums, then the RSAians kicked yer lilly white bums too
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: (Score:1)
Re: (Score:1)
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'.
Grotch? (Score:2)
You have a gross or unsavory crotch?
http://www.urbandictionary.com/define.php?term=Grotch [urbandictionary.com]
What should domain owners do? (Score:3, Interesting)
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: (Score:2)
Re: (Score:2)
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: (Score:2)
Because it's quiet complicated to get right and needs lots of automatic rekeying.
Quite quiet. Almost silently complicated.
Re: (Score:2)
Sorry for not being a native english speaker and thanks for the pointer. :-)
Re: (Score:2)
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 [demon.co.uk] 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 m
Re: (Score:2)
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.
Why DNSSEC? (Score:2, Interesting)
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? (Score:5, Insightful)
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: (Score:2)
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: (Score:2)
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 g
Re: (Score:2)
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 reco
Re: (Score:2)
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 DNSSE
Re: (Score:1)
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: (Score:2)
> 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: (Score:1)
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: (Score:3, Informative)
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: (Score:1)
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: (Score:1)
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 [greyhatindia.com] 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 y
Re: (Score:2)
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: (Score:2)
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: (Score:2)
...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 [auckland.ac.nz].