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 Procedure1. 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:
Round Up;; 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
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.