DNS and DNSSEC
As many in the tech community will know, the DNS is a core part of the Internet’s infrastructure. It provides the vital function of mapping human-readable names (such as www.surf.nl) to machine readable information (such as 2001:610:188:410:145:100:190:243). When the DNS was designed in the 1980s, security was not a prime concern. Consequently, the DNS turned out to be vulnerable to attacks. This led to the development of the DNS Security Extensions (DNSSEC), which add authenticity and integrity to the DNS using digital signatures. DNSSEC is an increasingly important tool to enhance not only the security of the DNS, but also the security of many other Internet protocols, such as, e.g., the secure transmission of e-mail across the Internet.
While DNSSEC development started as early as the 1990s, deployment did not take of in earnest until a serious security flaw (the so-called “Kaminsky” vulnerability) in the DNS was unveiled in 2008. This vulnerability posed a serious threat to trust in the DNS, and sparked a renewed interest in deploying DNSSEC. Operators of top-level domains, such as .com and .nl, invested in deploying DNSSEC, and in 2010 the top of the DNS hierarchy, the so called Root of the DNS, was also secured using DNSSEC. In July of 2010, at the time the Internet Engineering Task-Force (IETF) met in Maastricht, The Netherlands, DNSSEC was deployed for the first time at the root of the DNS.
When DNSSEC was deployed at the Root of the DNS, a vital key was introduced, the so-called Key Signing Key for the root of the DNS. This key is extremely important for the validation of the digital signatures in DNSSEC. It is the trust anchor for all chains of trust in the DNS. The figure below shows a typical DNSSEC chain of trust, in this case the chain that is required to validate a signature for www.example.com:
The figure shows the relationship between all the signatures that need to be validated to check the authenticity of a record for “www.example.com”. Most importantly, the figure shows that this chain of trust terminates at the root of the DNS (shown as an anchor).
The Key Signing Key for the Root of the DNS has remained the same since it was first introduced in July of 2010. This, however, is about to change.
Root KSK Rollover
It is common practice to replace signing keys in DNSSEC. In fact, many best practice documents recommend doing this every one to two years. Given that the Root KSK has remained the same going on seven years, it is clear that it is overdue for a change. This year, for the first time since DNSSEC was deployed at the Root of the DNS, the KSK will change. This so-called key rollover will take place over a period that roughly lasts for nine months, and starts in July 2017. During this process, a new KSK will be introduced, which will become active in October 2017.
Why does this matter and why should I care?
As mentioned before, all chains of trust in DNSSEC start at the Root KSK. Thus, if this key is replaced, this means that the newly introduced key will have to be used for verification of trust chains from that moment onward. This is of key importance for so-called validating DNS resolvers. Validating DNS resolvers verify the signature in DNSSEC on behalf of clients. If a signature fails to validate, this is treated as an indication of a security problem, and the validating resolver will return an error to the client. Effectively, this stops the client from accessing any content behind the name for which the signature fails to validate. And this is why this Root KSK rollover matters a lot. If validating DNS resolver do not pick up the new Root KSK, they will fail to validate all DNSSEC signatures. This failure is not just limited to DNSSEC-signed domains. Validating DNS resolvers will validate signatures at all levels of the DNS. Thus, if, for example, you want to access “cnn.com”, which itself is not DNSSEC-signed, a validating DNS resolver which does not have the correct Root KSK as trust anchor will return an error for an attempt to resolve this name, since it will be unable to validate the signatures in .com and at the root of the DNS.
Summarising: validating DNS resolvers that fail to pick up the new Root KSK will catastrophically break down when the new Root KSK is introduced.
A Virtual Canary-in-the-Coalmine
Because of the potential impact of the Root KSK on the Internet, and on validating DNS resolvers in particular, SURFnet has started a project to monitor its impact. Together with five partners (the University of Twente, Northeastern University, NLnet Labs, RIPE NCC and ICANN) we have started the “Root Canary” project. The goal of this project is twofold. First, we will perform operational monitoring of validating DNS resolvers, to verify that they keep working correctly during the entire Root KSK rollover process. This gives us an opportunity to act if major problems occur during the Root KSK rollover process. Second, we will record all the measurements we perform for the monitoring part and will perform a detailed analysis of this data after the Root KSK rollover completes. This allows the Internet community to draw lessons from this first ever Root KSK rollover, in the hope that it can inform policy for future DNSSEC changes at the Root of the DNS.
Test your resolver
As part of this project, we have developed an online DNSSEC validation checking tool. This tool performs an extensive test of the DNS resolver(s) configured on your system to see which DNSSEC algorithms it supports. This is useful in two ways. First, it confirms if your DNSSEC validating DNS resolver works correctly. Second, it can show you if your validating DNS resolver supports modern DNSSEC algorithms, such as those based on Elliptic Curve Cryptography. The picture below shows an example of the output of this tool for a resolver that supports most modern DNSSEC algorithms.
ICANN maintains a website dedicated to the Root KSK rollover. We also maintain a website for the Root Canary project, on which we post regular updates about the progress of the project and intermediate results. The Internet Society, finally, runs the Deploy 360 programme, which stimulates the deployment of new Internet technologies such as IPv6 and DNSSEC. Their site contains links to many resources about DNSSEC.