DNSSEC technical details

I originally posted a more simplistic overview of DNSSEC that is a good first read if you're new to the subject.

I'm going to borrow and re-work a little content I made from a future post about SSHFP but that is relevant to DNSSEC.

With SSL/https we have Certificate Authorities (CAs) that do some sort of verification and then sign SSL certs. Our web browsers (Internet Explorer, Firefox, Opera, Safari, etc.) come with a list of CA Roots. This allows us to verify without going external to our clients that a Public Key is legit, as it has been signed by a pre-trusted CA Root.

...

DNS suffers from the same MitM attack problem as anything else. However, we can sign DNS with DNSSEC and we already have trusted equivalents of CA Roots, in the form of the DLV.isc.org system, and eventually with DNSSEC signed DNS roots.

DNSSEC is not the same as CA roots, but it is close in some ways. In a high-level overview nutshell, the root "." DNS servers would generate DNSSEC keys. They would sign the records for the gTLD (.com, .net, .org, etc.) and ccTLD (.us, .ca, .uk, .de) domains. Further, they'd sign the signing keys of those TLDs, vetting them that they were legitimate. This would continue to flow down, with the gTLD/ccTLD signing their zones and signing the keys of the domains under them (roysdon.net, roysdon.org, roysdon.us, etc.). In turn, end-operators of DNS systems would sign their zones. Now all you have to do is have the proper public key of the root "." zone and you can verify any DNS zone's records and not tampered with.

Kind of, in a vaporware way of speaking, coming to a DNS server near you, one of these days, eventually. So the problem is two-fold:

The root "." zone is not signed. Their are all sorts of political problems with this, like who is going to hold the private keys for that, etc. Second, most of the TLDs are not signed (few are, .SE being the first major ccTLD, .ORG being the first major public gTLD, and .GOV is signed as well). Worse still, there is the problem of getting Registrars on board to get the end-operators DNS keys signed even when that does go live.

Second, as a chicken-in-the-egg kind of problem, since hardly nothing is signed, ISPs don't operator DNS resolvers that support DNSSEC. Comcast has some trials going on, and will probably be one of the first to deploy.

Third, is that for an end-user, applications sure don't know anything about DNSSEC. Since the ISPs don't support it and the zones don't support it, why bother writing it in (yet). Just like your webbrowser notifies you if a connection's SSL certificate is invalid, we need the same thing for DNS lookups.

Well, soon, hopefully. There are a few stale Firefox add-ons to allow clients to do DNSSEC checks themselves.

There are work-arounds for the root "." and TLDs not being signed or signing domains yet as well. The ISC DLV (DNSSEC Lookaside Validation) is one such method. My signed zones (roysdon.us, roysdon.net, roysdon.org) are all in the ISC DLV. So if you add the ISC DLV keys to your DNS server and enable it, you'll be able to verify my DNS data via DNSSEC's Authenticated Data (AD) flag.

So that's the next problem, running a DNS server that supports DNSSEC. Minimal DNSSEC support requires BIND9.3. This was first available in RHEL5/CentOS5 (BIND 9.3.4), but not RHEL4/CentOS4 (BIND9.2.4). Further, there are different changes that have occurred with DNSSEC, so for full DNSSEC NSEC3 support (which .GOV, .ORG, roysdon.net, and more security-minded others use), you need BIND 9.6.

BIND 9.6 isn't available until Fedora 11, and F11 isn't something that you want to use in a production environment since it's only supported for 13 months. However, in the meantime you could take the F11 BIND and compile the Source RPMs (srpms) yourself for CentOS5/RHEL5, which is what I've done. The downside is that you must make sure you watch for new bug announcements and continue to roll-your-own until CentOS6/RHEL6 ships and we get the new BIND 9.6 version officially fully supported. You can track the BIND versions at Distrowatch for both CentOS and Fedora.

ITAR is another trust anchor method, and can be used in conjunction with ISC DLV. Again, ITAR this requires BIND 9.6. ITAR is much like the original HOSTS file that everyone had to update when the Internet was first born, before DNS. It changes and updates and everyone knows it is a temporary fix, but it makes you less dependant should there be a failure at ISC DLV.

If you've still got questions, as I know I glossed over things rather fast, and mostly this was a note-keeping exercise for myself about versions and links to more details, here is one DNSSEC Howto I started with, which has more details as how this all works.

There are plenty of links for DNSSEC justification. The biggest one I can see is that you don't want your zone data spoofed, and while the whole solution isn't there yet, you can do your part as a dns operator (either as a zone owner or as an ISP). Then when the other pieces come into play, you're already set, and have experience.

The good news is with DNSSEC, we will have not just two things protecting us from a MitM attack and going to the wrong website: SSL CAs (which are constantly getting attacked) as well as a secure DNS. It's still not perfect, and doesn't protect us from an on-the-wire MitM attack, but it does stop us from getting DNS tricked to going to the wrong IP address which could then be making use of an SSL exploit. It's all about layers and layering on the security.