Do you have DNSSEC validation enabled?

In July 2010, we saw an important Internet milestone: the Domain Name System (DNS) root zone was signed with DNSSEC, the DNS security extensions.

DNS was designed without much thought given to security, but DNSSEC adds much-needed authentication and data integrity features. With DNSSEC, information in the DNS, including the root zone, can be cryptographically signed. DNS clients can validate the resulting signatures to have more trust that the data coming out of DNS is the same as what the owner put in and signed, and that the data hasn’t been modified in transit.

Broad adoption of DNSSEC will make DNS spoofing attacks more difficult and, perhaps more importantly, it will lead to innovative new protocols that take advantage of a trustworthy DNS.

This development has already started. For example, a protocol called DANE (DNS-Based Authentication of Named Entities, see RFC 7671) allows the X.509 certificates used by Transport Layer Security (TLS) to secure websites to be authenticated using DNSSEC instead of (or in addition to) a certificate authority (CA).

So why was signing the root zone so important? This step enabled and encouraged additional DNSSEC deployment further down in the DNS hierarchy, and the reason boils down to how trust works in DNSSEC.

How DNSSEC Works

With DNSSEC, a DNS response now contains not only an answer but also a digital signature over that data made by the private key of the zone where the data originates. Validating this signature requires the zone’s public key – which DNSSEC conveniently stores in the DNS – so obtaining the required key for validation is simple. But how do you trust that key? Who vouches for its authenticity?

In the X.509 certificate world, this vouching is the job of a CA. An X.509 certificate is a CA’s digitally signed statement that a particular entity has a specific public key. If you trust a CA’s public key, then you trust the certificates signed with the CA’s corresponding private key.

DNSSEC has no equivalent of a CA. Instead, the only entity that can vouch for a zone’s public key is that zone’s parent in the DNS hierarchy. For example, only the .com zone can vouch for the public key of the example.com zone, and only the root zone can vouch for the .com zone’s public key. The root zone is the top of the DNS hierarchy, so it has no parent to vouch for its key. Instead, the root zone’s key must be configured as a “trust anchor”. A trust anchor is a key that is declared trustworthy, rather than deriving its trustworthiness by being signed by another key.

So to validate a digital signature over DNS data, you start at the root’s trust anchor and build a “chain of trust” – with parent zones vouching for child zones – until you reach and trust the public key of the zone the data came from. Then you use that key to validate the data’s signature. (The actual process, not surprisingly, is a bit more complicated. There are usually two keys, not just one, for each zone, but a chain of trust starting at the root is the important concept here.)

This description of the DNSSEC trust model illustrates the importance of the root zone’s key: it is the starting point of the chain of trust. In DNSSEC terminology, the key used as a trust anchor is usually a kind of key called a key-signing key, or KSK. Any device performing DNSSEC validation needs to have the root zone’s KSK configured as a trust anchor. DNSSEC validation is usually performed by recursive name servers, which are operated by Internet Service Providers (ISPs) and enterprises, so these devices, and many others, have the root zone KSK configured.

Rolling the Root Zone KSK

The root zone KSK has not changed since the root was first signed back in July 2010. But just as it’s good practice to change passwords regularly, likewise no cryptographic key should live forever, either. ICANN’s plan had always been to change the root zone KSK after at least five years of operation. In cryptographic parlance, this process is called “rolling” the key.

In May 2016, ICANN announced its intention to roll the root zone KSK after many discussions with the multistakeholder community. Since there are no problems with the key or its operation, ICANN has taken a slow and cautious approach to the changeover process. ICANN first convened a design team of invited experts to help develop the plans for rolling the root zone KSK. A design team released a report, which ICANN staff operationalized, resulting in a set of rollover plans that were published in July 2016.

The rollover process will take more than a year, with major milestones occurring each calendar quarter. (The root zone KSK is only used once per quarter at special “key ceremonies,” so major events in the rollover process coincide with these ceremonies.) The plans also include the ability to back out at multiple points in case problems are encountered.

The rollover process is well underway. The new root zone KSK was generated in October 2016, and will be published in DNS on 11 July 2017.

The most important date to be aware of is 11 October 2017, which is when the root zone KSK changes. 

By that time, any device performing DNSSEC validation needs to have the new root zone KSK configured as a trust anchor. If the new trust anchor isn’t configured, DNSSEC validation will fail, causing DNS outages.

Obtaining the New Root Zone Trust Anchor

Devices can be updated with the new root zone trust anchor manually or automatically.

1. To manually update your system’s trust anchor, you must:
   • obtain the trust anchor;
   • ensure that it is authentic; and
   • update the validator configurations by hand.

The official source for the root zone trust anchor file is on the Internet Assigned Numbers Authority (IANA) website. The trust anchor file is signed by the ICANN CA and can be validated with a detached signature file. More information about obtaining and validating the trust anchor file is available at the IANA website.

2. If your software supports automated updates of DNSSEC trust anchors via the “Automated Updates of DNS Security (DNSSEC) Trust Anchors” protocol defined in RFC 5011, the KSK should be updated automatically at the appropriate time and you should not need to take additional action. However, devices that are offline during the rollover will have to be updated manually if they are brought online after the rollover is finished.

ICANN is offering a test bed for operators or any interested parties to confirm that their systems handle the automated update process correctly. More information is available at go.icann.org/KSKtest.

An estimated 750 million people worldwide use recursive name servers that perform DNSSEC validation and therefore could be affected by the KSK rollover. But by being aware of the rollover and being prepared, we can keep DNS resolution working for Internet users. Please make sure you are ready for the rollover by 11 October 2017, and help us notify Internet operators and user communities in your region before the change occurs.

For more information about the rollover, including resources to help prepare for the upcoming change, visit icann.org/kskroll. If you still have questions, email us at globalsupport@icann.org with “KSK Rollover” in the subject line.

Matt Larson is VP of Research in the Office of the CTO at ICANN. He’s worked with DNS and other Internet technologies for nearly 30 years at Dyn, Verisign and HP.

Rate this article

---

The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.