DNSSEC Comes To .Net Zone Today
62
wiredmikey sends news that as of today VeriSign has enabled DNSSEC on the .net zone. This is one milestone in a years-long process of securing the DNS against cache poisoning and other attacks. Next step will be for VeriSign to sign the .com root early next year."Having DNSSEC enabled for .net domains... [is] important as it represents one of the most critical implementations of DNSSEC technology, since .net serves as the underpinning for many critical Internet functions. The largest zone to be DNSSEC enabled to date, .net currently has more than 13 million... domain name registrations worldwide."
Re: (Score:2)
Re:Typos (Score:4, Funny)
Re: (Score:2)
As opposed to what? The good ol' days when editors read the articles and proof-read submissions? When men were real men, and small furry creatures, etc etc.
And ponies. Pink ponies [flickr.com].
Re: (Score:2)
I remember it well, it was GLORIOUS!
Re: (Score:3)
As opposed to what? The good ol' days when editors read the articles and proof-read submissions? When men were real men, and small furry creatures, etc etc.
Ah, the good ol' days... when the men were men, the women were men, and the girls were FBI agents.
Re:More security in what way? (Score:5, Insightful)
The USA is your boogieman.
but hey, it's popular to hate them, lets go for it! They are magically worse than everyone else (many of whom do exactly the same, some are better, some are worse) because they have power and you aren't with them.
Grow up. They'll drop down a few pegs in the next 10-20 years, and the EU, China or both will become a more formidable power. Don't worry. I hope you are in one and can enjoy the other side of the idiocy you are propagating.
Re: (Score:3, Informative)
Damn, you're dumb. He's calling for a decentralized system, which doesn't rely on any government, including the EU and China.
Re: (Score:2)
username girlintraining, and you think it's a guy?
Re: (Score:1, Interesting)
Re:More security in what way? (Score:5, Insightful)
I was thinking more or less the same thing.
The point is that a good domain name system implementation needs to be secure against protocol attacks. DNSSEC secures it against hackers, but makes it more vulnerable to political attacks. Because DNS was designed to be centralized.
The problem with currently emerging alternatives is that they're designed to be decentralized, making them vulnerable to protocol attacks. However, a good p2p implementation would use an underlying hierarchy based on the anonymity of the name authorities, and they would be able to establish further authority points. But that protocol isn't even invented yet as far as I recall, and it would require a hell lot of thought and encryption.
In any case, more cryptographic security is better, not worse. If you want someone to blame, it's the inventors of DNS for establishing a US-based name authority. Oh wait, the Internet was invented in the US, by none other than the DARPA. Go figure.
Re:More security in what way? (Score:5, Informative)
I was thinking more or less the same thing.
The point is that a good domain name system implementation needs to be secure against protocol attacks. DNSSEC secures it against hackers, but makes it more vulnerable to political attacks.
You do know that DNS root servers [root-servers.org] are located (and co-located) around the world (20+ countries I believe off the top of my head), and they are all equal. The only US-centric part is that the designated maintainers (ICANN [icann.org] and IANA [iana.org]) are US based organizations, in large part due to historically originating in the US, and this does have the benefit being one of the best legal protection for free-speech in the world.
If you want an alternate system [wikipedia.org], edit your DNS root hints [internic.net] file.
Join the Internet Society [isoc.org], ICANN [icann.org], and your national domain registrar [icann.org] if you want to make difference.
So? (Score:3)
And yet when the US government asked VeriSign to revoke domain names, all the root servers mirrored that decision. Just because DNS is distributed doesn't make it the least bit decentralized.
Re: (Score:2)
"Join the Internet Society, ICANN, and your national domain registrar if you want to make difference."
Oh please. It was the ISOC that helped hand the domain name system to the government. In 1997 Bob Shaw, ITU, Albert Tramposch WIPO and Don Heath ISOC met at an OECD meeting. They cooked up a plan that became IAHC then ICANN. The alternative was an industry consortium that would operate the DNS the way the Internet itself operates - free of a US government regualatory authority.
It was Steve Wolff that libe
Free speech vs. DNS (Score:2)
this does have the benefit being one of the best legal protection for free-speech in the world [i.e. in the US].
Q: what do you get if you register free-speech.us at a DNS provider?
A: a free-speech zone.
Re: (Score:1)
Oh wait, the internet was invented in the US, by none other than the DARPA. Go figure
That couldn't be any more wrong.
What DARPA invented was what people commonly mistake the Internet for, or more what they WANT it to be.
The internet is the opposite of what DARPA created, in other words, locked down, centralised and EASILY knocked out by nuclear war.
Hell, it is easily knocked out by a country you piss off simply by them nullrouting everything and letting the mostly neutral BGP do the rest of the work. (well, this is less of a problem these days because there are smarter filters that communi
Re: (Score:2)
Each major region gets a representative (or a few), they all take votes on actions to do, just like other groups such as UN.
There's your problem. As bad as the US has been in recent years, it's no where near as bad as a grouping would be. Sure it would give the EU more of a say, but it would also give China a bigger say as well, and probably other governments known for far more abusive practices with regards to the internet.
Re: (Score:1)
DNSSEC secures it against hackers, but makes it more
vulnerable to political attacks. Because DNS was designed to be
centralized.
I don't understand. DNS is centralized and is somewhat vulnerable
to political attacks. But how does DNSSEC make it more vulnerable?
(It seems no different to me).
Re: (Score:2)
But how does DNSSEC make it more vulnerable?
(It seems no different to me).
It doesn't. But it makes a nice straw-man, doesn't it?
For someone with control of the root, DNSSEC makes things only slightly more difficult, but definitely does not make it easier.
Re:More security in what way? (Score:5, Informative)
You really don't know what DNSSEC is, do you?
What DNSSEC does: DNSSEC provides a means for an end-user to determine the authenticity of the DNS data they receive by proving that only someone in control of the domain could have served the record.
What DNSSEC does not do: DNSSEC does not provide for the security of data being exchanged between systems.
With DNSSEC, each domain admin holds their own private keys. Nobody else should ever see them. Chain of authenticity is provided by each parent domain signing the delegation records provided by the child domain.
So, for the "government" to "exert control" over your domain, they would have to completely spoof every parent of your domain. This would affect not just your domain, but all domains in that TLD. Pretty sure if everyone in .com all broke at the same time, someone would notice. In short, this makes it harder for someone to take control of your DNS. If the "government" wanted it to be easier, they never would have allowed the root to be signed.
And let's face it, DNSSEC was not designed for you. DNSSEC is designed for businesses, banks and other large entities who are trying to protect their customers from being spoofed. It is just another tool like SSL. And, IMO, anyone who uses SSL certs should use DNSSEC. If you don't use SSL, it's highly unlikely you need DNSSEC.
But hey, if all you want to do is spew ridiculous conspiracy theories, never mind, rant on.
Re: (Score:2)
This is definitely theoretically possible. However, you're going to have to convince the major application developers to play along.
Though to be fair, it would only be the equivalent of the cheaper certs that only verify domain control for authority when issuing certs. The higher-level certs truly do involve a third-party verification of identity of the cert recipient.
Re: (Score:2)
Though to be fair, it would only be the equivalent of the cheaper certs that only verify domain control for authority when issuing certs. The higher-level certs truly do involve a third-party verification of identity of the cert recipient.
Seems to me that would be adequate for most purposes. The main thing the cert mechanism catches is a man-in-the-middle forging a response from a machine within a domain, while it's the user's job to go to the correct domain in the first place. If the servers and the comp
Re: (Score:2)
Chain of authenticity is provided by each parent domain signing the delegation records provided by the child domain.
So, for the "government" to "exert control" over your domain, they would have to completely spoof every parent of your domain. This would affect not just your domain, but all domains in that TLD. Pretty sure if everyone in .com all broke at the same time, someone would notice.
Or they could pressure the parent domain into signing their own bogus delegation records, the same way they currently can pressure them into serving bogus delegation records (such as customs seizing all those trademark-and-copyright-infringing domains a few days ago). This relies entirely on each parent domain being trustworthy about what they sign, which is a bit difficult if you don't trust the government that they're subject to.
Re: (Score:2)
Sure, they could pressure the parent to supply bogus records. On the other hand, they always could have pressured them to change the NS records, which they would also have to do if they published bogus DS records.
So at absolute worst, no security was gained from the "government". It cannot be made worse, because any theoretical compromise by the governing agency was already possible, and much easier before.
Re: (Score:2)
Re: (Score:1)
And the answers from such a server would not be accepted. DNSSEC does not prevent DoS attacks and actually make some DoS attacks easier. What it does do, when properly implemented, is prevent applications seeing false data.
The only data not covered by signatures is referrals and compromised referrals don't lead to false data being returned to the application. It will be rejected at the validation stage.
Re: (Score:2)
"Nobody else should ever see them."
*Should* being the operative word.
The other problem with DNSSEC is, once you sign your domain the government can assign the domain to somebody else via UDRP, but without your key signing, it aint gonna work. The trade mark guys are gonna freak out when they figure this out.
Re: (Score:3)
DNS has allways been more or less centralized, and was allways controlled by the US. The US can already disable domains as they please, DNSSEC or not. The only difference with DNSSEC is, that it now impossible to change DNS data without having access to the keys. This makes DNS more secure for everyone, including private individuals.
Has been sued almost immediately. (Score:5, Funny)
Re: (Score:1)
Actually, they sued Verisign for making .net more secure than .Net
Certificates in DNS. (Score:5, Interesting)
Does DNSSEC allow storing SSL certificates in the DNS records? It would seem that this is an awesome way of getting free SSL certificates.
Also, I doubt anyone bothered with this, but does DNSSEC have any way of saying "this domain should only be contacted with SSL"? That would prevent SSL stripping MitM attacks.
Re: (Score:2)
RFC4398 [ietf.org] defines a CERT record to store certificates, but I have no idea if it's supported by current DNS resolvers (I doubt it is).
Re: (Score:1)
It was supported by the very oldest resolvers. A good resolver library handles unknown record types and passes them back to the application to handle as a opaque blob. res_query() from BIND 4.8 can retrieve CERT records for the application. Just ask it to retrieve type 37 for you.
Re:Certificates in DNS. (Score:4, Informative)
DNS is just a database. You can store anything you want in it. If you're storing something you want lots of people to care about, it's best to get a dedicated record type for it, but if you just want to play around you can use TXT records. There is a record type for certificates.
So yes, you can do
www.example.com IN TXT "this server should only be contacted by HTTPS. Do not gopher!"
but web browsers are not likely to ask for that record. Feel free to develop a browser which does or ask the browser developers to include this feature.
Re: (Score:2, Interesting)
Does DNSSEC allow storing SSL certificates in the DNS records? It would seem that this is an awesome way of getting free SSL certificates.
Also, I doubt anyone bothered with this, but does DNSSEC have any way of saying "this domain should only be contacted with SSL"? That would prevent SSL stripping MitM attacks.
There are CERT records that can have X.509 (SSL/TLS) certificates:
http://tools.ietf.org/html/rfc4398
Just like a browser can do a look up for the A record of a web site, it could also look up the CERT record if it was so inclined.
With DNSSEC it is now possible to check the veracity of the CERT RR to prevent man-in-the-middle accounts. DNSSEC could be used as a substitute for certificate authorities.
Re: (Score:3)
With DNSSEC it is now possible to check the veracity of the CERT RR to prevent man-in-the-middle accounts. DNSSEC could be used as a substitute for certificate authorities.
This is news for me, and extremely interesting. Are there any browsers/mail clients/whatever supporting this? Anything worth reading about it? Instructions on how to implement it and make some experimental use of it?
Can we lobby for this to be implemented in browsers, email, and the rest?
Currently, you either have to pay some CA, or be your own CA which nobody trusts, and have everyone install the cert or constantly click through the warnings
maze.
Re: (Score:1)
Experimental one, yes. Production ones, not yet.
The IETF WG DNS-based Authentication of Named Entities (dane) [ietf.org] has recently been setup to help standardise how to do this.
Re: (Score:2, Informative)
Coincidentally, today this working group became official:
http://www.ietf.org/mail-archive/web/keyassure/current/msg01078.html
Objective:
Specify mechanisms and techniques that allow Internet applications to
establish cryptographically secured communications by using information
distributed through DNSSEC for discovering and authenticating public
keys which are associated with a service located at a domain name.
Actually, they enabled it yesterday (Score:3)
Actually, .net was enabled sometime around 16:00 GMT yesterday. They just didn't announce it until today.
I was doing testing of a DNSSEC system yesterday, and one of my test cases change state on me unexpectedly. (Signed zone in an unsigned parent)
doing away with DNS? (Score:2)
Re: (Score:2)
Re: (Score:2)
In DNS speak a "zone" defines names with a common suffix. It may either define those names directly or it may delegate them to sub-zones hosted on other servers.
So when you lookup www.slashdot.org then (asusming nothing is cached) the recursive resolver looks up www.slashdot.org in servers responsible for the root zone which tells it where the .org zone is hosted. Those servers tell the resolver where slashdot.org zone is hosted and finally those servers tell the resolver the requested details for www.slash
PowerDNS (Score:2)
I'm aware that DNSSEC is currently supported in test builds of PowerDNS, but consider this a vote for having it available in stable by the time .com gets signed..
(In the interim, I figure having BIND slaves serving data off of PowerDNS would work, since PDNS can handle DNSSEC RR types)
Re: (Score:1)
BIND 9 has supported DNSSEC for the last 10 years. It was used in production testbeds (BIND 9.1 and 9.2) which lead to a redesign of the trust model at delegation points.
BIND 9.3 onwards has supported the current DNSSEC with NSEC3 support being added in BIND 9.6. RSASHA256 (used in the root) and RSASHA512 support was added in BIND 9.6.2 and BIND 9.7.