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: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:Maybe we should get some software support? (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.
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.