In a little over two weeks, precisely in 17 days (on 11 October 2018 at 16:00 UTC), ICANN will roll the Domain Name System Security Extensions (DNSSEC) root Key Signing Key (KSK).

If you are a Domain Name System (DNS) and DNSSEC expert already engaged globally on the topic, you are certainly both well aware and ready for the rollover. This article is probably not for you! If however, you are out there focused on your day to day running or managing a DNS infrastructure and just wondering what the heck is this rollover stuff, and how it affects you, please read this to the end.

Let me start by telling you—don’t panic!

First, check if you are running DNSSEC on your infrastructure. If the answer is a definitive NO, then do not go further; the rollover and this article are not relevant to you. Chill and wait to hear from us in a separate blog talking about why it may be important for you to consider running DNSSEC.

But, If you are running DNSSEC or have heard your vendor or service provider talking about something that sounds like that, then you need to assess your readiness for 11 October.

In short, what is DNSSEC?

DNSSEC is a function added to the regular DNS to ensure no one tampers (accidentally, experimentally, or with the intention to harm) with the DNS answer to an address query sent by an Internet device (i.e., phone, computer, etc.). DNSSEC allows users of information provided by DNS to confidently know: “Did this DNS response really come from the zone it was supposed to come from?” and “Am I sure no one has modified the data since it was generated as a response to my query?”.

DNSSEC provides that assurance by using a mechanism that utilizes a cryptographic key to sign each DNS response, with the ability to follow the DNS tree up to the root to make sure that DNS information you are dealing with is authentic. In short, it helps guarantee that an online user ends up going to their desired online destination.

For the process to work globally, and following the distributed architecture of the DNS, each administrator of a given zone has to participate by signing DNS data their system manages. It also provides a pointer back to its parent to ascertain that administrators have the “right” to serve data from a given zone as per the delegation tree. This process creates a chain of trust that goes up to the root. This is important—it’s all about providing users a degree of trust that they are going where they want to go in the DNS.

Ok, let me stop there as it is the only thing I want to say about how DNSSEC works (which is not the main topic of this blog).

So what exactly is happening now?

As I mentioned previously, the root zone of the DNS tree has its data signed by a key managed by ICANN, as the recognized administrator and authority over that zone. To ensure the integrity of the public part of the key used to sign the zone, there is another key (it is like you are signing the envelope of an already signed letter inside the envelope). That key signing key for the root zone is what ICANN is going to change for the first time ever since DNSSEC has been implemented at the root level (moving from KSK-2010 to KSK-2017).

Obviously, changing the key will impact the chain of trust. Anyone out there running a DNS with a validating resolver will need to make sure that its own servers are properly set up to point to the new KSK (KSK-2017).

At this point, ask yourself three questions:

“am I running a DNS infrastructure?”,
“am I running DNSSEC”
“am I doing validation”

If you answered YES to all of them, then this article is for you. YOU NEED TO URGENTLY CHECK if your setup is configured to also use the new key! How can you check if you have the key that is planned to be used starting only on 11 October? Well, the process is done in the way that the two keys are both published (even if only one, the old one, is used to sign the ZSK). KSK-2017 has been published in the root zone for more than a year (starting on 11 July 2017).

DNS servers running DNSSEC know how to pick multiple KSKs but only validate using the active one. Checking that your validating server has this behavior by properly picking the new key is all you need to do right now.

How do you check it?

The ICANN organization has led a very aggressive information and outreach campaign over the past three years. That campaign includes a very well documented step by step process to check your validating DNS readiness. Click here and follow the steps that are relevant to your environment and check if you have the right key.

If everything is in place and you can see KSK-2017, thumbs up! You are READY! You should not see any problems in your system on 11 October.

What if the check above shows that you don’t have the KSK-2017 configured yet? Don’t worry, follow the instruction provided for “How to update your validating resolver with the latest trust anchor” here. Follow the instructions relevant to your environment. When you are done, you can go back to the first link above to see if you are now picking the right key!

If you have any specific question related to this, you can direct them to your service provider or to at ksk-roll[at]icann.org.

At this point, you may be wondering if end users have to do anything if you are worried about failing in the dark on 11 October? Yes! Immediately bring this up with your IT team. Ask them precise questions such as:

• Does our DNS infrastructure have DNSSEC activated?
• Does it do DNSSEC validation?
• Are we ready for the KSK rollover ICANN is planning on 11 October 2018?

If you do not get a convincing answer, kindly ask them to simply check the quick guide put together by ICANN and its KSK rollover resource page. By doing so, you have done your part to help us raise the awareness of what is coming up.

We are less than 20 days before the new key start signing the zone signing key (ZSK). We all have to act now, not only by checking ourselves, but also sharing the information around us.

ICANN as manager of the root zone has worked hard to do its part, which is making sure that technically it can roll the key and have a well-elaborated plan to do so. The distributed nature of the global DNS infrastructure holds everyone running DNSSEC responsible for making sure that customers/users they serve are not impacted by the rollover at the root level.

What exactly one can expect on 11 October?

In general terms we are not expecting any type of big bang, some data analysis suggests that more than 99% of users whose DNSSEC resolvers are validating will not be affected by the KSK rollover. Depending on your DNS/DNSSEC context you will see different system behavior.

• If you rely on a resolver that does not perform DNSSEC validation, you will not see any effect from the rollover.
• If you rely on a resolver that is properly set up and has properly picked the new KSK-2017, you will not see any effect from the rollover.
• If you relay on resolvers that really do not have the new KSK-2017 in their trust anchor configuration, you will likely start seeing the effects at some point in the 48 hours after the rollover happens.

It is impossible to predict when the operators of affected resolvers will notice that validation is failing, so it is important for everyone managing an Internet infrastructure to know that this rollover is happening and closely monitor their system behavior the few days following 11 October.

You can refer to these measurements that support current impact analysis:

1. ICANN research team measure and publish its assessment of the readiness of validating resolvers’ through queries we see at the root level RFC 8145 Root Trust Anchor Reports
2. APNIC Labs’ Measurement of the Root Zone KSK Trust