Don’t Panic: DNSSEC isn’t DO or Die

Recent rumors that the Internet is doomed are just as overblown as all the rest, except perhaps when AOL started letting its users onto the Internet a fate from which the Internet never really recovered. The current rumor relates to DNSSEC (also known as Domain Name System Security Extensions), which cryptographically signs DNS results. This is done to prevent DNS cache poisoning and similar spoofing attacks. A number of sources have reported that the root DNS servers will begin signing responses this Wednesday, May 5, 2010. The concern is that after DNS responses are signed, they will be larger than normal DNS packets. To make things more concerning, older versions of the DNS specification state that DNS responses will never be larger than 512 bytes. There may be a large number of legacy firewall rules that still enforce this restriction. If the larger packets trip one of these rules, they will be discarded.

The good news is that only one Root DNS server, J, will be changed on May 5. DNSSEC support has been rolled out to all root servers. May 5 actually marks the end of this rollout process that began in January 2010. Even then, the changes that occur on May 5 are just a test. This is known as the DURZ rollout. DURZ stands for Deliberately Unvalidatable Root Zone it's a fake key that cannot be used to validate the zone. The actual root key has not been created yet. ICANN has solicited applications from individuals to become trusted community representatives to verify the creation of the root key and its use to sign the root zone.

All the other root servers are already serving signed zones, but only if you ask for it. According to RFC 3225, the response will only be signed if the DO (DNSSEC OK) flag is set. As long as your resolver or client doesn't set this flag, you shouldn't see any difference.

It's not a bad idea to test if DNSSEC works in your environment. You can do this by using DNS-ORAC's reply size test tool, or simply using dig. If you add the argument "+dnssec" to a dig query, then it will turn on the DO flag. Please note these tests are to verify if a firewall or other device will block large packets. The tests will not tell you if your DNS resolver software is capable of supporting DNSSEC.

For Example:

Normal (none) DNSSEC Query:



user@prompt$ dig edu @199.7.83.42

; <<>> DiG 9.4.3-P3 <<>> edu @199.7.83.42 ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53931 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 7, ADDITIONAL: 8 ;; WARNING: recursion requested but not available


;; QUESTION SECTION:

;edu. IN A
;; AUTHORITY SECTION:

edu. 172800 IN NS a.gtld-servers.net.

edu. 172800 IN NS c.gtld-servers.net.

edu. 172800 IN NS d.gtld-servers.net.

edu. 172800 IN NS e.gtld-servers.net.

edu. 172800 IN NS f.gtld-servers.net.

edu. 172800 IN NS g.gtld-servers.net.

edu. 172800 IN NS l.gtld-servers.net.




;; ADDITIONAL SECTION:

a.gtld-servers.net. 172800 IN A 192.5.6.30

c.gtld-servers.net. 172800 IN A 192.26.92.30

d.gtld-servers.net. 172800 IN A 192.31.80.30

e.gtld-servers.net. 172800 IN A 192.12.94.30

f.gtld-servers.net. 172800 IN A 192.35.51.30

g.gtld-servers.net. 172800 IN A 192.42.93.30

l.gtld-servers.net. 172800 IN A 192.41.162.30

a.gtld-servers.net. 172800 IN AAAA 2001:503:a83e::2:30

;; Query time: 29 msec

;; SERVER: 199.7.83.42#53(199.7.83.42)

;; WHEN: Mon May 3 14:22:30 2010

;; MSG SIZE rcvd: 292

Query with DNSSEC OK flag set:



user@prompt$ dig +dnssec edu @199.7.83.42






; <<>> DiG 9.4.3-P3 <<>> +dnssec edu @199.7.83.42

;; global options: printcmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41980

;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 9, ADDITIONAL: 9

;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;edu. IN A ;; AUTHORITY SECTION: edu. 172800 IN NS a.gtld-servers.net. edu. 172800 IN NS c.gtld-servers.net. edu. 172800 IN NS d.gtld-servers.net. edu. 172800 IN NS e.gtld-servers.net. edu. 172800 IN NS f.gtld-servers.net. edu. 172800 IN NS g.gtld-servers.net. edu. 172800 IN NS l.gtld-servers.net. edu. 86400 IN NSEC ee. NS RRSIG NSEC edu. 86400 IN RRSIG NSEC 8 1 86400 20100509070000 20100502060000 55138 . tPrT3Me8lYFUNjiP8wdeJ2Xrwokhaa4snnmMjP2N30VnMHMcr1JbmfXa YGtchk9RIbhOMMdbwrYQS1aQsIuoJA+rEYFqe471rKdiN2kNC3JPqUoP HgNscjKy9+yuJJbDuGmSBoZIWlxPCWS0QNnHxvuRfx3OlM5n22o/ZHKw 8is= ;; ADDITIONAL SECTION: a.gtld-servers.net. 172800 IN A 192.5.6.30 c.gtld-servers.net. 172800 IN A 192.26.92.30 d.gtld-servers.net. 172800 IN A 192.31.80.30 e.gtld-servers.net. 172800 IN A 192.12.94.30 f.gtld-servers.net. 172800 IN A 192.35.51.30 g.gtld-servers.net. 172800 IN A 192.42.93.30 l.gtld-servers.net. 172800 IN A 192.41.162.30 a.gtld-servers.net. 172800 IN AAAA 2001:503:a83e::2:30

;; Query time: 27 msec ;; SERVER: 199.7.83.42#53(199.7.83.42) ^[[A;; WHEN: Mon May 3 14:22:23 2010 ;; MSG SIZE rcvd: 486
The signed response includes the RRSIG ( Resource Record Digital Signature) record, which contains the signature itself. If you make a dig query with +DNSSEC set and you see a response that includes an RRSIG, you will likely be able to use signed zones without a problem. Furthermore, because the DO (DNSSEC OK) flag is not set by default in the majority of DNS clients you shouldn't experience any odd behavior with this change.