Are you ready? Are your systems prepared so that DNS will keep functioning for your networks? One week from today, on Thursday, October 11, 2018, at 16:00 UTC ICANN will change the cryptographic key that is at the center of the DNS security system – what we call DNSSEC. The current key has been in place since July 15, 2010. This is a long-planned replacement.
If everything goes fine, you should not notice and your systems will all work as normal. However, if your DNS resolvers are not ready to use the new key, your users may not be able to reach many websites, send email, use social media or engage in other Internet activities!
This change of this central security key for DNS is known as the “Root Key Signing Key (KSK) Rollover”. It has been in discussion and planning since 2013. We’ve written many articles about it and spoken about it at many conferences, as have many others in the industry. ICANN has a page with many links and articles at:
But here we are, with only a few days left and you may be wondering – how can I know if my systems are ready?
The good news is that since the Root KSK Rollover was delayed 1 year, most all of the DNS resolver software has been shipping for quite some time with the new key. If you, or your DNS server administrators, have been keeping up with recent updates, you should be all set.
1. Test if you are doing DNSSEC validation
Before you do anything else, you should first check if you are doing DNSSEC validation on your network. As noted in ICANN’s guidance document, go to a command-line / terminal / shell window and type:
dig @<IP of your DNS resolver> dnssec-failed.org a +dnssec
For example, using Google’s Public DNS Server, the command would be:
dig @8.8.8.8 dnssec-failed.org a +dnssec
If the response includes this text:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL
then you ARE doing DNSSEC validation and should read the rest of this article.
If the response instead includes:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR
… well, you are NOT doing DNSSEC validation. You can skip the rest of this article, go have a beverage, and not have to worry about the Root KSK Rollover on October 11. However, you should also read up on DNSSEC and understand why you start validating to raise the level of security and trust on your network. (But, at this point, you might as well wait until October 12 to deploy it.)
If you are doing DNSSEC validation, read on.
Two notes:
- Unfortunately if you are not an administrator of your DNS resolvers, there are limited mechanisms to check if you have the new key. There are a couple of possibilities (see #2 and #3a below), but otherwise you will need to contact your DNS administrators / IT team and point them to this blog post and other resources.
- In DNS / DNSSEC circles the root key is also referred to as a “trust anchor”.
2. Try the Sentinel KSK Test
For a small percentage of you reading this, you might be able to use the “sentinel test” that is based on an Internet draft that is in development. You can do so at either of these sites:
Right now there is only one DNS resolver (Unbound) that implements this sentinel test. Hopefully by the time we do the next Root KSK Rollover, some years from now, this will be more widely deployed so that regular users can see if they are protected.
[UPDATE: the Knot DNS resolver also supports the Sentinel Test in its version 3.0.0 release – see the release notes.]
However, for most of us, myself included, we need to go on to other methods…
3a. Check if your DNS resolvers have the new Root KSK installed – via various tools
There are several tests you may be able to perform on your system. ICANN has published a list at:
That document lists the steps for the following DNS resolvers:
- BIND
- Unbound
- PowerDNS Recursor
- Knot Resolver
- Windows Server 2012RS and 2016
- Akamai DNSi Cacheserve
- Infoblox NIOS
For BIND users, ISC2 also provides a focused document: Root KSK Rollover in BIND.
3b. Check if your DNS resolvers have the new Root KSK installed – via specific files
If you have command-line access to your DNS servers, you can look in specific files to see if the new key is installed. The current key (“KSK 2010”) has an ID of 19036. The new key has an ID of 20326. As Paul Wouters wrote in a Red Hat blog post today, these keys can be found in these locations in Red Hat Linux:
- bind – see
/etc/named.root.key - unbound / libunbound – see
/var/lib/unbound/root.key - dnsmasq – see
/usr/share/dnsmasq/trust-anchors.conf - knot-resolver – see
/etc/knot-resolver/root.keys
Look in there for a record with an ID of 20326. If so, you are all set. If not, you need to figure out how to get the new key installed.
Note – these locations here are for Red Hat Linux, CentOS, and Fedora. Other Linux distributions may use slightly different file locations – the point is that there should be a file somewhere on your system with these keys.
4. Have a backup plan in case there are problems
As Paul notes in his post today, it would be good to have a backup plan in case there are unexpected DNS problems on your network on October 11 and users are not able to resolve addresses via DNS. One suggestion is to temporarily change your systems to give out one of the various sets of “public” DNS servers that are operated by different companies. Some of these include:
| IPv4 | IPv6 | Vendor |
|---|---|---|
| 1.1.1.1 | 2606:4700:4700::1111 | Cloudflare |
| 8.8.8.8 | 2001:4860:4860::8888 | Google DNS |
| 9.9.9.9 | 2620:fe::fe | Quad9 |
| 64.6.64.6 | 2620:74:1b::1:1 | Verisign |
You can switch to one of these resolvers while you sort out the issues with your own systems. Then, once you have your systems correctly configured, you can switch back so that the DNSSEC validation is happening as close to your users as possible (thereby minimizing the potential areas of the network where an attacker could inject malicious DNS traffic).
5. Plan to be around on 11 October 2018 at 16:00 UTC
Finally, don’t schedule a day off on October 11th – you might want to be around and able to monitor your DNS activity on that day. This Root KSK Rollover has been in the works for many years now. It should be a “non-event” in that it will be “just another day on the Internet”. But many of us will be watching whatever statistics we can. And you’ll probably find status updates using the #KeyRoll hashtag on Twitter and other social networks.
The end result of all of this will be the demonstration that we can safely and securely change the cryptographic key at the center of DNS – which allows us to continue improving the level of security and trust we can have in this vital part of the public core of the Internet!
Image credit: Lindsey Turner on Flickr. CC BY 2.0
P.S. This is NOT what the “Root key” looks like!
Acknowledgements: Thanks to Ed Lewis, Paul Hoffman, Paul Wouters, Victoria Risk, Tony Finch, Bert Hubert, Benno Overeinder, Hugo Salgado-Hernández, Carlos Martinez and other members of the dnssec-coord discussion list for the discussion that informed this post.