If you’re like me someone (quite possibly pointy haired) probably came running up to your desk in the last day or two telling you how the internet is about to come crashing down around us (yes, Cisco did promise it’d never be the same!) due to the deployment of DNSSec which is happening at the moment, and asked what you were doing about it. Articles like this really don’t help.

DNSSec

DNSSec is something we all need to start looking at, and it is doing to deliver a lot of security benefits. It’s also something which we need to actively test and probably change things within our infrastructures to make work. For a good overview of DNSSec, start your reading at wikipedia.

As with all DNS related subjects, there are two separate issues. Firstly, what we do with the domains we own – i.e. when do we start signing them – simple answer, not until the next tier up has (the current work is on the root servers, when that’s complete the TLD’s will be done, then you can start looking at your domains!). Secondly, how does it affect how we resolve other people’s domains. This is where the current publicity is focused, and where we will probably have to do a little work soon.

In a simple scenario, where you have stub resolvers in your organization (i.e. your DNS servers point out to your ISP for recursive queries), there is little you need to change in the short term. This is mainly down to the fact that the main difference will be an extra flag set in the response to say ‘this is Authenticated Data’.

If however, you do recursive lookups yourself (i.e. your DNS servers don’t have a forwarder set, they just go out the root servers and start doing a full recursive lookup) then there is a change. Put simply, it will be asking for more data in the response from the various servers it talks to, using an extended version of DNS called EDNS. When the whole system is filled with signed DNS records, you’ll be getting answers back which contain records larger then 512bytes (and probably fragmented packets). Most firewalls will block these large UDP DNS packets by default, as it has become accepted security practice to do so.

It’s important to note that some firewalls will know the difference between EDNS, and will not apply the restriction to EDNS. For example, in earlier versions of PIX (6.3.2 and below), you had to manually configure the DNS fixup to permit DNS packets with the longer length :

fixup protocol dns maximum-length 4096

in more recent versions, it would be covered by :

policy-map type inspect dns preset_dns_map
parameters
message-length maximum 4096

but here’s the thing, it’s EDNS not DNS, so it doesn’t actually affect it. However, all firewalls are different in their support for EDNS, you do need to check this on your firewall/router to be sure that it’s supported.

Testing

A good way to tell if your firewall/router is blocking these larger DNS packets, is to use the test listed at OARC. Here are two tests, the first one running to a non-EDNS capable DNS server (OpenDNS), and the other running to a EDNS capable one (It took me ages to find one! Verizon UK – 158.43.128.1 if you want to test). In both cases, they are running through an ASA (8.2.2) with default DNS message length of 512 :

dhughes@dynamips:~$ dig @208.67.222.222 +short rs.dns-oarc.net txt
rst.x476.rs.dns-oarc.net.
rst.x485.x476.rs.dns-oarc.net.
rst.x490.x485.x476.rs.dns-oarc.net.
“208.69.34.6 DNS reply size limit is at least 490″
“208.69.34.6 lacks EDNS, defaults to 512″
“Tested at 2010-04-14 15:32:28 UTC

Here – EDNS is not available.

dhughes@dynamips:~$ dig @158.43.128.1 +short rs.dns-oarc.net txt
rst.x3827.rs.dns-oarc.net.
rst.x3837.x3827.rs.dns-oarc.net.
rst.x3843.x3837.x3827.rs.dns-oarc.net.
“62.189.58.236 sent EDNS buffer size 4096″
“Tested at 2010-04-14 16:10:18 UTC”
“62.189.58.236 DNS reply size limit is at least 3843″

Here is a response which is considerably larger than 512. This means we can get the traffic through our firewall.

Summary

The Internet isn’t broken. You should check to be sure that your firewall will pass the EDNS traffic ASAP, and if not, make the appropriate changes. You can tell the pointy haired boss who’s sweating in the corner, that you’ve fixed the internet, and it’ll all be fine…