ARIN Implements DNSSEC 44
wmbetts writes with this quote from an announcement by the American Registry for Internet Numbers:
"On 27 April, ARIN placed Delegation Signer (DS) records into in-addr.arpa and ip6.arpa. Now DNSSEC validation will occur from the root down if you properly set up your DNSSEC-aware recursive resolver. For most DNSSEC-aware recursive resolver operators, nothing needs to be done for this change to be in effect as long as you have configured your DNSSEC-aware server to use ICANN's trust anchor for the root zone."
Re: (Score:2)
Re: (Score:3)
What language was that, and what does that mean to all of us who have no clue what that means?
Seriously--I don't barge into a lecture for 7th-year med students and say "WTF?!? What's a ganglia? What kind of language is this?!?!??!!one1."
(especially in this day and age where Google is about 40msec away)
The real question is... (Score:2)
... is it actually a good idea to use ICANN's trust anchor for the root zone, given their history?
Also, is this likely to make life harder for alternate roots?
Re: (Score:2)
No and Yes.
If, for your second question, you want to send mail to a Yahoo! user, from an alternatively name-rooted host.
Now, can I interest you in finest quality and 99% pure, Monongahela all-vegetable ingots?
Do you use them for your DNS root? (Score:3)
then you should use them for your DNSSEC root.
Unless you are using an alternate DNS root then you are already trusting ICANN, and DNSSEC will help prevent you from man-in-the-middle attacks, decreasing the number of untrustworthy people who can mess with your DNS queries.
DNS-SEC (Score:2, Interesting)
Introducing the intractable problems of commercial CAs to the remediable problems of DNS.
Great solution.
Re:DNSSEC (Score:5, Interesting)
You are confused. DNSSEC (no hyphen) does not use certificates nor CAs.
DNSSEC uses an anchored chain of trust system applicable to only hierarchical systems. It is similar in may ways to PGP, but, as long as a DNS operator chooses to trust a root key (not cert), the rest of the trust is cryptographically chained to the bottom of the tree.
The system does place a great deal of responsibility on the root, but, if you read the way the keys are handled, the actual "keys to the kingdom" are spread across a number of people, all well known and not a part of ICANN. A fair percentage are academics. It is a very elegant and very carefully thought out system and is cryptographically provable.
Also, similar to SSH, only you hold the private keys for your zones. You don't give those to anyone.
Re: (Score:2)
I mostly agree with your, but your last sentence.... well, let's have a look shall we ?:
"Also, similar to SSH, only you hold the private keys for your zones. You don't give those to anyone."
Which is similair to SSL/TLS protocols like HTTPS. ;-)
DNSSEC enables self-signed TLS (Score:2)
Which is similair to SSL/TLS protocols like HTTPS.
The difference here is that with TLS, your CA-signed certificate is sold separately. DNSSEC in theory would let a domain owner store the fingerprint of a self-signed TLS cert in the domain's zone file because the domain registrar acts as the CA. The only problem left is lack of support for SNI (name-based virtual hosting extension for TLS) in IE <= 8 and Android <= 2.3.
Re: (Score:2)
SNI is available for IE7 and IE8 on Vista and IE8 on Windows 7, it is actually the library which is part of Windows XP where the problems is with SNI, which also effects Safari on Windows XP.
Re: (Score:2)
SNI is available for IE7 and IE8 on Vista and IE8 on Windows 7
IE 9 is also available for these platforms. The rule of thumb that I have been following is that in practice, IE <= 8 means IE on XP. Or how is this invalid?
ISP Hijacking (Score:5, Interesting)
Re: (Score:1)
No. But it is a step in that direction. When everything is secured with NSEC3, if you drop all unsecure answers, they will not be able to hijack NXDOMAIN.
Re:ISP Hijacking (Score:5, Informative)
It all depends on how the Hijacking works. All this (DNSSEC) does is validate that the DNS information (IP address) for a given hostname is correct. This will stop rogue DNS servers from reporting an incorrect IP address for a give hostname.
From my understand of the ISP hijacking of web traffic, they are doing deep inspection of the packet data, looking for requests that are HTTP, and inserting data (be it a redirect or ads). They are performing a man-in-the-middle attack on unencrypted data.
The only way to stop ISP hijacking is to use https everywhere. Even with that, ISPs could use man-in-the-middle and inject a new SSL cert, but it probably wouldn't be signed by a trusted source (so the user would get an evil warning message from their browser).
Re: (Score:1)
No, that's not how any of that works. First of all, the news is about the reverse lookup domains, which is what you use when you have an IP address and want to know its DNS name. This is somewhat important but doesn't affect typical client usage. Secondly, ISPs usually don't hijack 404s but NXDOMAIN errors: In case of a 404, the domain resolves, the server answers but the URL doesn't exist on the server. What ISPs actually intercept are unresolvable domains, and only if you use their recursive resolver. Par
Re: (Score:2)
We are both correct. I wish I could update my other post saying that you added the more common case (and easier to do for ISPs).
In my post, I was talking about the shit Mediacom has been doing [dslreports.com].
Re: (Score:2)
If ISPs should then actually go for the man in the middle attack that you described, DNSSEC will probably also stop that, because a standard for using DNSSEC to distribute SSL keys is being worked on.
TLS (formerly SSL) allows only one certificate per IP address. The solution used to be allocating an IP address for each distinct certificate, but that's a lot harder now that IPv4 addresses are exhausted. SNI, an extension to TLS, allows a separate certificate per hostname, but IE <= 8 doesn't know SNI and can therefore see the certificate of only the primary domain on that IP address.
Re: (Score:1)
No, a 404 is 'DNS is found, HTTP URL is not found'.
But, if you mean NXDOMAIN 'DNS is not found' responding, yes, if your ISP enables DNSSEC in their recursive resolver.
Re: (Score:2)
The literal case of a 404 will not be affected.
The more common case of re-directing queries to port 53 to their server which responds with the address of their internal advertizing page (such as the one Comcast uses) will be stopped and Comcast has already acknowledged that they will be forced to stop the practice. I do give them credit for agreeing to enable DNSSEC on their servers even though it does break this advertizing mechanism.
Maybe we should get some software support? (Score:2, Interesting)
All of these stories on DNSSEC make me wonder about what software supports it. As far as I know, Windows 7 and the various *BSD and Linux operating systems have a resolver that supports DNSSEC. No browser I am aware of can tell you if the security status based on DNSSEC. There is not really a point for DNSSEC if you cannot indicate its status somehow to the user or have the browser reject spoofed pages, or have the browser force secure resolving, etc.
Re: (Score:2, Informative)
Here's what I do on Windows XP: Use Unbound [unbound.net] as a local recursive, caching and validating resolver that returns an error when a signature doesn't validate. The DNS in my network connections points to 127.0.0.1.
Re:Maybe we should get some software support? (Score:4, Informative)
There is a plugin [mozilla.org] for Firefox.
Do I need to do anything? (Score:2)
I've been hearing about DNSSEC for quite a while now, but still don't understand if I need to find out more and possibly do something about it.
I take care of about a dozen small zones under various TLDs. The DNS servers for these zones are all running Bind 9 on Debian. None of the domains has a real certificate, but they all use self-signed certs for things like mail with SSL/TLS, VPNs, etc.
I also manage company DNS servers, which are the resolvers for the machines on the LANs.
So, is there anything special
Re:Do I need to do anything? (Score:4, Informative)
There are 2 things you could do.
1. The easiest thing you can do is to use a DNSSEC capable resolver and give it the 'root key material' and have it setup to update automatically. Every 6 or so months a new key will be generated, so it needs to be updated. Most of the software has a mechanism for that. The root key material is at: https://data.iana.org/root-anchors/ [iana.org] If you use Unbound, you just create a file with the right information and put in the configuration file: auto-trust-anchor-file: "/usr/local/etc/unbound/root.key"
That way, everything which can be checked will be checked and you will be less vulnerable to DNS attacks.
2. Deploy DNSSEC for the zones you manage: The most used TLDs are all signed, although they may not all be available to the general public yet. You will obviously need DNSSEC-capable authoritive DNS-server software or use Phreebird as a proxy. When your zone data is signed, obviously clients/resolvers need to be able to check what you signed, you do this by communicating the 'DS'-record (dig +norec @ns1.zone.tld zone.tld DS) to your registrar or TLD-operator, the same people who you are paying for the domain/where you communicate the name and possibly IP-addresses of your DNS-zone. Some registrars might not be ready, but other are. You might need to shop around. Unfortunately you will need to that every X months as well.
On desktops and so on, there currently are very little tools which make use of it.
You could put the SSH-fingerprint in DNS which is signed by DNSSEC and enable VerifyHostKeyDNS, that way when you choose yes when connecting to a SSH-server the first time, you can have more confidence that what you are connecting to is the real server.
There are efforts to make it available for the browsers and so on:
https://os3sec.org/ [os3sec.org]
There is a DANE-proposal which makes it possible for the browser to check DNS/DNSSEC and use it for certificate-chain checking for HTTPS instead (or together with) the current CA-system.
Re: (Score:2)
Yes, you can split the KSK/ZSK and all that, it is optional. Probably most will want to do so though.
SSH needs a local validating resolver, yes. I don't know why I left that out, but it can forward to the network resolver for quick response.
There are a lot of details I left out. ;-)
North America like Europe ? (Score:2)
I'm glad that North America (ARIN) is now doing what Europe (RIPE) did earlier this month.
Re: (Score:2)
So North America is *weeks* behind Europe? WEEKS!!??!?! That is soooo shameful.
Re: (Score:2)
So which zones does RIPE sign? None? So not the same.
Gonna kick it root down (Score:2)
So how you wanna kick it?
Gonna kick it root down!
So how we gonna kick it?
Gonna kick it root down!
So how we gonna kick it?
Gonna kick it root down!
Break it on down, gonna kick it root down
It's not a putdown, I put my foot down
And then I'm makin' some love, I put my root down
Like 'Sweetie Pie' by the Stone Alliance
Everybody knows I'm known for droppin' science
Beasties -- ahead of their time AND helping save Admins everywhere the trouble of statically configuring ARIN’s trust anchors.
DJB points out DNSSEC is insecurely administered (Score:2)
http://www.vimeo.com/18417770 [vimeo.com]
He also suggests DNSCurve as an alternative. Would be interesting to try setting up both on the same name server.
Re: (Score:2)
Judgement Day (Score:2)
I know this is pretty much unrelated, but I really wish they would figure out a way to write about DNSSEC that doesn't make it sound like we just got done turning on Skynet...