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. I've written many articles about it and spoken about it at many conferences, as have many others in the industry. [Including a recent article here at CircleID: The Root KSK Rollover? What Does It Mean for Me?] 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".

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.

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:

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!

By Dan York, Author and Speaker on Internet technologies - and on staff of Internet Society Dan is employed as a Senior Content Strategist with the Internet Society but opinions posted on CircleID are entirely his own. Visit the blog maintained by Dan York here. Visit Page

If you are pressed for time ...

... this is for you. More and more professionals are choosing to publish critical posts on CircleID from all corners of the Internet industry. If you find it hard to keep up daily, consider subscribing to our weekly digest. We will provide you a convenient summary report once a week sent directly to your inbox. It's a quick and easy read.

I make a point of reading CircleID. There is no getting around the utility of knowing what thoughtful people are thinking and saying about our industry.

Vinton Cerf, Co-designer of the TCP/IP Protocols & the Architecture of the Internet