The domain name system (DNS) community has spent two decades implementing the DNS Security Extensions, or DNSSEC, to help safeguard the authenticity and integrity of DNS data. At this point, it’s relatively straightforward for the administrator of a DNS server to configure DNSSEC validation, and many administrators have done so.
But now, for the first time, administrators whose DNS servers use DNSSEC validation may need to take action to prevent widespread failure of DNS resolution. On October 11, the root zone’s key-signing key rollover occurred. If you don’t know what that means, let me explain.
First, we’re talking about the root zone, which is maintained by the Internet Corporation for Assigned Names and Numbers (ICANN), in the internet’s DNS. The root zone is the very top of the internet’s namespace, an administrative “container” of sorts, that houses delegation information to com, net, fr, uk, and every other top-level domain on the internet — so, clearly, it’s an important thing. If your DNS servers were to lose access to the root zone for an extended period, they would cease to resolve internet domain names.
Secondly, and more importantly, is the key-signing key. Many of the most important zones on the internet, including the root zone, are “signed” using a protocol called the DNS Security Extensions. (DNSSEC is used with the intention to combat the threat of cache poisoning.) “Signing” a zone using DNSSEC is something like digitally signing an email message: You give DNS servers the ability to validate responses from the zone, proving the data in the response comes from the authentic zone and hasn’t been modified since it was signed. To perform this validation, you use a cryptographic key that’s published alongside other data in the zone.
To validate data from an arbitrary zone in DNS, you can look up the key for that zone. But you need to validate that key, too. It’s easy to imagine a bad guy compromising a zone and changing all the data in the zone, including the key. So, each key is validated by a signature in the parent of the zone that contains it. For example, the key in Forbes.com is validated by a signature in the com zone, and the key in com is validated by a signature in the root zone.
Think about that for a moment. That means that ultimately, you use the root zone’s key to validate all signed data in DNS. That’s a very important key.
For practical purposes, most zones signed with DNSSEC actually use a pair of cryptographic keys. Basically, using two keys simplifies administration: Cryptographic keys need to be rotated, or rolled over, every so often — and more frequently if you use them a lot. If you use a zone’s key to re-sign the data in the zone each time you change it, the recommendation is that you change your key once a month. But each time you change your key, you have to have it re-signed by the folks who run your zone’s parent, which is a hassle.
Consequently, DNSSEC experts generally recommend using two keys for each zone: a zone-signing key, or ZSK, which you use to sign the data in the zone, and a key-signing key, or KSK, which you only use to sign the zone’s keys. The ZSK may need to be changed monthly, but the KSK, which isn’t used nearly as often (only monthly, or whenever the ZSK changes) can go much longer without a rollover.
Well, the time has finally come for the root zone’s KSK to roll over. And because all trust in DNSSEC is ultimately derived from that key, all DNS servers that perform DNSSEC validation need to know about the new root zone KSK. Some newer DNS servers support a feature that automatically tracks changes to keys, but older DNS servers don’t, and some folks who run newer DNS servers might not have that feature configured.
What does this mean to you? Now that the root zone’s KSK rollover has occurred, organizations may find themselves unable to resolve any domain names if they haven’t ensured every DNS server that uses DNSSEC to validate DNS data is configured with the new root zone key-signing key. Here’s what you need to do:
1. First, check to see whether your DNS servers are configured to perform DNSSEC validation. If they aren’t, there’s nothing more to do. (Though, you might ask yourself why you aren’t using DNSSEC.)
2. If your DNS servers are using DNSSEC validation, check to see whether they support something called “RFC 5011.” RFC 5011 is a document that describes an automatic mechanism to track changes to DNSSEC keys. If they support RFC 5011, you should be in good shape.
3. If your DNS servers are using DNSSEC validation and don’t support RFC 5011, you’ll need to configure them with a new key-signing key for the root zone. How you do that will depend on the make and model of the DNS server you run; check your vendor’s documentation for details.
For more information on the root zone’s key rollover, explore the resources available from ICANN.