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.
Further reading
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.
This was originally published on the SURFnet blog.
Comments 4
Comments are disabled on articles published more than a year ago. If you'd like to inform us of any issues, please reach out to us via the contact form here.
Stéphane Bortzmeyer •
With my Unbound resolver, I get results similar to yours but with Google Public DNS, it's more fun: https://framapic.org/HpnX0WIfdiMl/An1vwwGtuDXb.png Google handles GOST DS but not GOST signatures. Also, it SERVFAILs for RSA-MD5 signatures.
Stéphane Bortzmeyer •
It's with BIND that I get the most green dots: even GOST works fully: https://framapic.org/7UIoLRIEQelV/ci1qZP1I94FA.png The only missing stuff is the Bernstein crypto.
Stéphane Bortzmeyer •
Strange problem with a Knot resolver: only orange (open padlock) dots. The resolver validates, I'm pretty sure of it: % dig A labs.ripe.net ; <<>> DiG 9.9.5-9+deb8u11-Debian <<>> A labs.ripe.net ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56289 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 8, ADDITIONAL: 9 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;labs.ripe.net. IN A ;; ANSWER SECTION: labs.ripe.net. 600 IN A 193.0.6.153 labs.ripe.net. 600 IN RRSIG A 8 3 600 ( 20170726090003 20170626080003 31785 ripe.net. jMr0wyDGah/o4e4yV5slTEwqlk6KK11NkWDaiagnIdJp vDO4z9U+MoGWHkdR2rX94kt+eLWgy+U48ygPwY0vyChn xnjcEZ+4DZ8ZfzsSQ+BHodKksujfiCdTeiw6HsrcwtEq AuvdJ19EF9v8c0lVjil46HUhfltgPT7/p+B2Ct0= ) ;; AUTHORITY SECTION: ripe.net. 2131 IN NS a3.verisigndns.com. ripe.net. 2131 IN NS sns-pb.isc.org. ripe.net. 2131 IN NS a1.verisigndns.com. ripe.net. 2131 IN NS manus.authdns.ripe.net. ripe.net. 2131 IN NS sec3.apnic.net. ripe.net. 2131 IN NS tinnie.arin.net. ripe.net. 2131 IN NS a2.verisigndns.com. ripe.net. 2131 IN RRSIG NS 8 2 3600 ( 20170726090003 20170626080003 31785 ripe.net. UlsAmef8O5ls8BHV4Is81uw5q4iWWN82SEgk5DVvT5t7 yN03+/Cl6B8XxcfhymW+/5ndBl2R673GKfamb3Xm2nVd g8JT27ScD6kpYLWTqqITb1+/4PXXyTcYhRVrrfBmjgFG NyyKreTi1mrfV5KConADv2PKk1ixuU8hMxdFnhk= ) ;; ADDITIONAL SECTION: sec3.apnic.net. 171330 IN A 202.12.28.140 sec3.apnic.net. 171330 IN AAAA 2001:dc0:1:0:4777::140 manus.authdns.ripe.net. 171330 IN A 193.0.9.7 manus.authdns.ripe.net. 171330 IN AAAA 2001:67c:e0::7 tinnie.arin.net. 171330 IN A 199.212.0.53 tinnie.arin.net. 171330 IN AAAA 2001:500:13::c7d4:35 manus.authdns.ripe.net. 2131 IN RRSIG A 8 4 3600 ( 20170726090003 20170626080003 31785 ripe.net. PUJXvQ3gFUNXBMgf4Rs5OuuAhLhlOVYMrL1vDKkeZRmY awgwQOJKkRiASVERXIWiyabTxTW+ziORa28QKsDhjRgv OLhPyBO6XJ4ol4bY1Yiecc78vi8lGBYq7Onnn6YYgHdm kAYzGp16ggAd6EitKsz+ymzkDF+HS1Jen7ZcNkI= ) manus.authdns.ripe.net. 2131 IN RRSIG AAAA 8 4 3600 ( 20170726090003 20170626080003 31785 ripe.net. lkXqjQBWK1WkEJUnD7SvzCKd8vpRKzBxWap69Ia4WiHS F8D99749X9NklhDtthD3R7c1umOwoAi7R6OIwjUnVFH8 Q+PBahvmJCefnj/RAEYw4H7HQyvPkSjGhlQ27/vN2ApL p8IzQ+Ym6G1cuxSAVG9NKq6WrgXON3I17JKE0mY= ) ;; Query time: 457 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Tue Jun 27 20:56:19 CEST 2017 ;; MSG SIZE rcvd: 1035
Vladimír Čunát •
knot-resolver: that's really strange, and I can't reproduce that. Still, there is currently a significant problem there being fixed ATM. Followups best on https://gitlab.labs.nic.cz/knot/resolver/issues/210