nyckel-key-cc-by

DNSSEC key rollover time!

DNS service providers who have enabled DNSSEC validation should confirm that all their systems are updated with the new KSK as a trust anchor and verify the signature with the new KSK.

The mission of the Internet Corporation for Assigned Names and Numbers (ICANN) is to help ensure a stable, secure and unified global Internet. ICANN helps coordinate and manage the highest level of the domain name system (DNS), called the root zone. The root zone plays a critical role in how the DNS converts domain names to Internet addresses worldwide. Without this seamless DNS resolution process, the Internet could not operate the way it does today.

Since 2010 the root zone is digitally signed by using a security protocol called DNS Security Extensions (DNSSEC). DNSSEC adds a layer of trust on top of the DNS by providing a way to authenticate DNS data. The signature provides a means to check the authenticity of DNS data. By validating the DNSSEC signature the network operators are able to protect their users from a form of malicious attack known as “cache poisoning,” that could redirect their users’ traffic to an incorrect website and then, for example, steal passwords or other kinds of sensitive information.

DNSSEC deployment is optional and not all network operators have enabled validation of DNSSEC signatures, but operators who have activated it could be affected by an upcoming change that will take place this fall. The change means that an important parameter used to validate the authenticity of a signature in DNS, namely the key signing key (KSK) of the root zone, is replaced. The change will take place on October 11th, 2017.

What is this?

DNSSEC is a function that makes internet more secure by making it harder to manipulate the information that travels through the domain name system. By resolving queries in DNS it is possible to locate the right resource on the internet while surfing and sending e-mail to a certain host. DNS is a gigantic, distributed database which translates domain names to IP addresses, the unique number series that identifies internet connected computers. You may compare it to how a telephone catalogue maps names to phone numbers. DNSSEC is the only effective means to get a secure domain that cannot be victim of attacks where the responses of DNS lookups are forged. With DNSSEC the DNS responses are signed with cryptographic keys, and by validating the signature against the key of the root zone one can make sure that the query response originates from the right source and hasn’t been manipulated during transmission.

How does it work?

DNSSEC means that a user, when making a DNS lookup, by validation of signatures may be able to judge whether the content of the reply is originating from the right source or if it has been tampered with on its way. It is hard to forge information in DNS when it’s signed with DNSSEC without being discovered. For the general user DNSSEC reduces the risk of becoming a victim of fraud in for instance in bank transactions or online shopping, since it is easier for the user to confirm they are communicating with the right bank or shop, and not a fraudulent entity.

DNSSEC works by digitally signing records for DNS responses using public key cryptography. The correct DNSKEY record is authenticated via a chain of trust, starting with a set of verified public keys for the DNS root zone. The verified public key is the public part of the KSK (key signing key).

What’s going on?

On October 11th, 2017, the key (KSK) used since 2010 to sign the root zone will be replaced. Anyone who after this date doesn’t have the new key (KSK) configured on their name server application used to resolve DNS queries (resolvers) won’t be able to reach resources on the internet signed with DNSSEC, since the authenticity of the query response won’t be validated.

Why is it happening?

Primarily the key replacement is performed to raise the preparedness of the ICANN staff by practicing a key rollover. Even though a KSK doesn’t have a ”best before” date, and there are no known vulnerabilities, it is poor encryption practice to allow keys to live too long. There is also an advantage in practicing the processes and routines for key rollovers under normal and controlled circumstances. The situation may occur when conditions are more unfavorable, for example in an emergency where the key has been disclosed. If that were to happen, everyone involved would need to know how to change the key as part of crisis management.

Important dates

  • July 11, 2017:Publication of new KSK-2017 in DNS root zone
  • September 19, 2017:Size increases for DNSKEY response from root name servers
  • October 11, 2017:New KSK-2017 starts to sign the root zone DNSKEY RR set (the actual key rollover event)
  • January 11, 2018:Revocation of old KSK-2010
  • March 22, 2018:Removal of the old KSK-2010 from all of IANA’s HSM’s
  • August 31, 2018: The KSK rollover is considered to be completed

What do I need to do?

DNS service providers who have enabled DNSSEC validation should confirm that all their systems are updated with the new KSK as a trust anchor and verify the signature with the new KSK. This will happen automatically with most modern resolver software thanks to RFC5011. Updating the KSK is crucial for the validation of DNSSEC signatures for DNS resolvers to continue to work properly even after the key rollover. Without the correct root zone key (KSK) DNSSEC validation will cease to work and DNS resolvers won’t be able to answer any DNS queries about signed domains.

This means that if you have support for RFC5011, as for example in modern versions of Unbound or BIND, it is enough to verify that the new key is in place sometime during the second half of August. If it is not there by then, you will need manual intervention.

The 19th of September there will be an increase in the packet size of DNSKEY responses from the root name servers since several keys will be used for signing for a period of time. To test whether your systems can manage the increased packet size, consequently to check what the resolvers can handle, we recommend the use of https://www.dns-oarc.net/oarc/services/replysizetest

What are the consequences of not replacing the key?

DNSSEC validation will stop working for resolvers that has validation enabled but do not have the new KSK configured as a trust anchor.

What do I need to do if the automatic key rollover didn’t work?

It depends on what kind of software you are using in your resolvers. Either the key rollover takes place automatically or it will need manual intervention. To find out how it is in your case, please contact your software supplier. You can test if your systems support automatic key rollover by using ICANN’s Automated Trust Anchor Update Testbed available at https://go.icann.org/KSKtest

It would be prudent to check by the end of August if everything has worked as expected. By then you should find two KSK’s configured in your resolvers as DNSKEY/DS records.

Here is where you find more information!

Mailing List: https://mm.icann.org/listinfo/ksk-rollover

Follow ICANN on Twitter: @ICANN. Hashtag: #KeyRoll

Questions?

Contact registry@iis.se