Security is great when all the green lights are shining brightly and everything validates as intended, but what happens when you encounter failure? In this work we examine the behaviour of the DNS when security, in the form of DNSSEC is added, and we look at what happens when things do not happen as intended. What triggered this examination was a sudden increase in the traffic generated by secondary servers for the in-addr.arpa reverse zones in December 2009. Within hours the traffic levels from those servers had doubled. What was initially surprising was that this was not a malicious attack, but due to the combination of DNSSEC and cryptographic key distribution methods and the planned rollover of the keys for the zones being served on that day. We have found two widely deployed implementations of DNS resolvers that enter a mode of sustained, repeated and very rapid querying of DNS servers for DNSKEY and RRSIG Resource records, causing potential problems for both DNS servers and resolvers.

The problem is shown to be an outcome of the interaction of the distribution of key material and the regular rollover of the key signing key that forms the trust anchor for the signed zone. When these resolver implementations fall out of sync with the zone’s keys then they do not quietly fail, but instead they enter a period of sustained query thrashing, asking the same query from all the name servers of a zone with up to a thousand repetitions from each single initial seed query.

The signing of the root of the DNS and a hierarchical signing delegation from the root downward was intended to circumvent such problems of manual key management and synchronisation, because as long as the client was able to synchronise their key with the root key then there is no such problem of falling out of sync with individual zone keys. However there is a vulnerable period over the next six months when the DNSSEC-signed root is deployed with a deliberately unvalidatable root zone, or DURZ. Clients are meant to avoid loading a local key for the root during this period, as there is no valid public key. But our studies have shown that if a client does mistakenly load a key then the resultant query load of rapid-fire repeated DNSSEC queries and large DNSKEY responses may present traffic problems for both the client and the root servers themselves.

Further on, in mid-2010, the root will be signed with a key that can be validated. The current intent is to regularly roll this root zone key every 2 - 5 years. Our studies show that if clients continue to operate on a manner which does not fail quietly, but fails in a way that generates very high bursts of DNS queries, with repetition factors in the order of up to 300,000 repetitions per seed query in a typical case, then each root zone key rollover has the potential to pose a significant denial of service threat on the root of the DNS posed by such out-of-key-sync clients running the current code levels of DNS resolvers.

The full details of the study can be found at http://www.potaroo.net/ispcol/2010-02/rollover.html

About the Authors:

George Michaelson is a Research Scientist at APNIC, the Regional Internet Registry serving the Asia Pacific Region.

Patrik Wallström has been working on DNSSEC and the development of the registry system at .SE for seven years, and with computer security and open source for over 15 years.

Roy Arends is Senior Researcher at Nominet UK, the Internet Registry for .uk domain names.

Geoff Huston the Chief Scientist at APNIC, the Regional Internet Registry serving the Asia Pacific region.