DNSSEC and interoperation with corporate firewalls
As some of you may be aware, the DNS Security Extensions (DNSSEC) are currently being rolled out across the Internet DNS root server infrastructure. The goal of DNSSEC is to provide authentication of DNS responses so that if you visit a site such as www.amazon.com, you can be pretty sure that you actually reach Amazon.com rather than some fake site that is designed to steal your password and credit card information.
A recent Register article identified a potential problem with DNSSEC and corporate firewalls. This article is designed to explain the issues and help you to test your infrastructure to ensure you can receive DNSSEC-signed responses. Please be aware that our support desk cannot simply state whether your environment is compatible or not, you need to do your own research as the problem will more than likely depend upon your firewall configuration.
DNS was invented in an era where people mutually trusted each other and it was not necessary to add authentication. Unfortunately, as the Internet grew and became more commercialised, more and more unsavoury people started attacking the DNS with the intention of polluting it and using it as a way of subverting legitimate traffic and redirecting it to web sites whose sole intention was to scam the unsuspecting visitor.
DNSSEC has actually been around in one form or another for over a decade, but has suffered from a lack of momentum mainly due to its complexity. Now, however, with the widely publicised Kaminsky vulnerability highlighting fundamental DNS protocol issues and the increasing need to secure Internet communications for e-commerce, we are finally seeing DNSSEC gain the momentum it needs to make an impact.
One of the biggest obstacles to wide-spread DNSSEC deployment has been the lack of a signed root zone. Without a signed root zone, any top level domains that have been signed (e.g. org, .gov, .se etc.) have required additional configuration on every DNS server to ensure that responses from those domains can be validated.
Now this is all about to change. ICANN (The Internet Corporation for Assigned Names and Numbers) is in the process of signing the root zone on each of the 13 root server instances that sit at the top of the DNS hierarchy. On 5th May, the final root server will have its copy of the root zone signed, meaning that when any DNS server on the Internet queries the root, they will receive a signed DNS response.
Initially, these signed responses will deliberately unvalidatable (ICANN have deployed what they call the "DURZ" - Deliberately Unvalidatable Root Zone - try saying that after a few beers!). This will enable the root server operators to test the effect of enabling DNSSEC and switch it off quickly if there are widespread problems. Because the root zone is deliberately unvalidatable, it will not matter if DNSSEC is switched off during this period.
What's the problem?
The sort of problems that are anticipated are mainly to do with corporate firewalls. As the DNS response packets will now contain various additional DNSSEC records, the responses will more than likely exceed 512 bytes, which has traditionally been the maximum size for a DNS response packet. If the DNS response is less than 512 bytes, it can normally be sent via UDP, but if it is larger than 512 bytes, it is possible that the response may be truncated, in which case it is re-sent over TCP.
This wouldn't ordinarily be a problem, but many firewall operators block DNS traffic over TCP as that is traditionally used to perform zone transfers. However, by blocking TCP-based DNS traffic, firewall administrators are not only intentionally blocking zone transfers but may also now be inadvertantly blocking the larger responses required by DNSSEC.
This will ultimately result in Internet DNS resolution failing and various web sites becoming unavailable as the firewall starts to drop the larger DNSSEC responses from the root servers and other DNS servers operating DNSSEC signed zones.
There are exceptions though - modern versions of BIND will use a protocol extension called EDNS0 to extend the UDP buffer size up to 4096 bytes, but it relies on both ends of the DNS communication using this method to negotiate a UDP packet size. And some firewall technologies, such as CheckPoint SmartDefense, have been known to drop DNS traffic when EDNS0 is used, leading to some DNS operators actually disabling EDNS0 or limiting it to a 512 byte UDP packet size.
Ultimately the only way to find out if your firewall will allow DNSSEC responses is to test it by sending some DNS queries to one of the root servers operating a signed copy of the root zone. If you have access to the "dig" command, the following web sites provide a series of tests you can perform to check if your firewall is compatible:
If you do not have access to "dig", there is a small Java applet you can download and run:
After performing these tests, you should be in a good position to determine if DNSSEC will cause problems for you as it begins its inevitable rollout across the Internet.
After the root servers have been successfully running for a couple of months with the "DURZ", the root zone will be signed with a proper validatable DNSEC key, at which point a chain of trust will exist from any DNSSEC-signed domain all the way to the root. This will greatly simplify DNS server configuration and lead to an explosion in DNSSEC signed domains. The timeframe for this happening is quite short, in fact ICANN plan to sign the root zone with a valid key on 1st July.
Initially this will probably not make much difference to end-users, but I would expect to see Microsoft release Windows updates that add additional checks in Internet Explorer to highlight when you have reached a domain secured by DNSSEC. The other browser vendors may also do something similar.
Paul Roberts is the Technology & Solutions Manager at tuscany networks and can be reached at email@example.com