The Domain Name System (DNS) is undergoing a change that was started in December of 2009 and is intended to complete in July of this year, 2010. In the light of a number of exploits of vulnerabilities with DNS identified over the past year or so, a more secure implementation is being brought into play which could cause problems with connectivity in some cases.
The primary issue is that DNS is not authenticated. A hacker can insert equipment between the customer and the legitimate DNS server and intercept DNS requests and respond with an IP address to a malicious site.
The DNS is structured like a file system with the core servers at the root, this is called the “Root Zone”. If requests to these servers can be intercepted then the false responses can filter down through the Internet steering everyone to the malicious site.
The solution is to provide some way of identifying the responses from these servers and this is being done through extensions to the DNS which are collectively called DNSSEC (Domain Name System Security Extensions). Using DNSSEC, any DNS responses from the Root Zone servers will be digitally signed which will uniquely identify the response as valid.
So far so good, but there will be some changes required to store this extra information. So some responses will be larger than 512 bytes. This can be an issue with older firewalls (http://net.berkeley.edu/DNS/dnssec.html#dnssecfw). Domain name lookups may still work but may not be as fast as they were before. In addition, recursive name servers may be impacted and it is important to test for problems as soon as possible, see below for some suggested tests that can be done.
An aside to our customers, you do not need to worry as all Network Boxes include a full recursive name server which has been tested so that it is compatible with DNSSEC. Also, the Network Box firewall is able to pass the required responses in a secure, fast and efficient fashion.
Testing for DNS Compatibiity
The following tests are courtesy of Mark Andrews of the ISC (http://www.isc.org/). Companies should ensure that they have run these tests or something like them before May 5th when the major part of the work involved in changing over will be done. If you are Windows based then ‘dig’ is included in the Bind release for Windows available, free, at:
http://www.isc.org/software/bind/96-esv/download/bind96-esvzip
L.ROOT-SERVERS.NET is the first of the root servers to switch to a signed copy of the root zone and can be used for testing. This version of the root zone has been configured deliberately so that it cannot be validated. Its purpose is to allow operators to test whether they can receive signed responses cleanly.
Test Procedure
1. First test that a basic DNS lookup works to ensure the ROOT-SERVERS can be reached:
$ dig +nodnssec +norec +ignore ns . @L.ROOT-SERVERS.NET
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9367
;; flags: qr aa; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 15
…
…
2. Next test if the system can receive an answer that is greater than 512 bytes. This test simulates how named makes its initial queries. Most signed responses fit between 512 bytes and 1500 bytes and are returned in a single un-fragmented UDP packet. This test is designed to check this case:
$ dig +dnssec +norec +ignore ns . @L.ROOT-SERVERS.NET
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60117
;; flags: qr aa; QUERY: 1, ANSWER: 14, AUTHORITY: 0, ADDITIONAL: 21
. 518400 IN RRSIG NS 8 0 518400 20100307080000 20100228070000 23763…
…
…
3. If the system returns data like that above, the next step is to see whether the system can receive a response when greater than 1500 bytes. Such responses are normally fragmented, and this test will find out whether the firewall will pass fragmented UDP packets. Failure to pass such responses will force named to fall back to using queries which are likely to trigger the use of TCP, which should be avoided. Failure to pass such answers will also slow up the resolution process.
$ dig +dnssec +norec +ignore any . @L.ROOT-SERVERS.NET
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61647
;; flags: qr aa; QUERY: 1, ANSWER: 22, AUTHORITY: 0, ADDITIONAL: 21
. 518400 IN RRSIG NS 8 0 518400 20100307080000 20100228070000 23763…
. 86400 IN DNSKEY 256 3 8 …THIS/IS/AN/INVALID/KEY/…
…
. 86400 IN NSEC ac. NS SOA RRSIG NSEC DNSKEY
4. Finally, test that the firewall passes outbound TCP/IP DNS requests. Even when using the extension mechanisms for DNS (EDNS), some answers will not fit into a UDP packet. Such responses require queries to be performed over TCP.
$ dig +dnssec +norec +vc any . @L.ROOT-SERVERS.NET
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5409
;; flags: qr aa; QUERY: 1, ANSWER: 22, AUTHORITY: 0, ADDITIONAL: 21
. 518400 IN RRSIG NS 8 0 518400 20100307080000 20100228070000 23763…
. 86400 IN DNSKEY 256 3 8 …THIS/IS/AN/INVALID/KEY/…
…
. 86400 IN NSEC ac. NS SOA RRSIG NSEC DNSKEY
For each of the above tests, the ‘dig’ command will return a footer showing query time and response message size. You can verify these to ensure they make sense and that the query response time is acceptable. You might expect the following values:
;; Query time: 384 msec
;; SERVER: 199.7.83.42#53(199.7.83.42)
;; WHEN: Mon Mar 1 09:56:36 2010
;; MSG SIZE rcvd: 1906
Round Up
If you did not receive responses like the ones indicated above, then you will have to fix your firewall. If you did, then all is well and you should not have any problems when all the root servers are signing their responses.
If you have any questions about this then you can always post a question to us on Twitter (www.twitter.com/networkbox), email us on info@network-box.co.uk or contact your service provider for more information.
Network Box customers do not need to do anything but if you have any questions then please contact us by ticket or phone and the support team will be happy to help.