How To Test for DNS Compatibility

Friday, July 16, 2010

Simon Heron

A88973e7d0943d295c99820ab9aeed27

The following tests are courtesy of Mark Andrews of the ISC (http://www.isc.org/). 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.

Possibly Related Articles:
13372
Webappsec->General
DNS Security Management
Post Rating I Like this!
The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.