Root Key Rollover

For the re-launch of my blog I thought I'd revisit one of my posts from last year that didn't quite turn out to be correct. For several reasons, some good, some overly cautious and some naive, the Internet Root Key Signing Key (KSK) was not rolled over last year. It is currently scheduled to roll on the 11th of October 2018, but I'll talk more about that in another post in a few days. Below are the technical details which I documented last year and are still relevant today, with some minor changes for new features in DNS servers.

KSK Roll over October 11, 2018.

The KSK is already pre-published at the time of writing. On October 11 2018 it will be used to sign the root DNSKEY RRset. Most resolvers developed in the last 5 years support RFC 5011, which provides a mechanism to automatically update a new trust anchor (KSK), assuming you already trust the existing KSK. So, if you have a modern DNS server and that DNS server can correctly validate responses from the root today. Then you are very likely to be perfectly fine and a little bored on October 11. Feel free to break something then quickly fix it so that your users don’t take you for granted though. In early testing, some older releases of popular DNS servers did not correctly update their stored trust anchors. Meaning that those systems would break unless their trust anchor files were manually updated. If you've patched your DNS server application in the last year, you'll be fine.

Checking Your DNS Server

The existing key, which is currently signing the root DNSKEY RRset is identified as key ID: 19036

1.       172800  IN  DNSKEY  257 3 8 AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq QxA+Uk1ihz0=

The new key is identified as key ID: 20326

1.           172800  IN  DNSKEY  257 3 8 AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTOiW1vkIbzxeF3 +/4RgWOq7HrxRixHlFlExOLAJr5emLvN7SWXgnLh4+B5xQlNVz8Og8kv ArMtNROxVQuCaSnIDdD5LKyWbRd2n9WGe2R8PzgCmr3EgVLrjyBxWezF 0jLHwVN8efS3rCj/EWgvIWgb9tarpVUDK/b58Da+sqqls3eNbuv7pr+e oZG+SrDK6nWeL3c6H5Apxz7LjVc1uTIdsIXxuOLYA4/ilBmSVIzuDWfd RUfhHdY6+cn8HFRm+2hM8AnXGXws9555KrUB5qihylGa8subX2Nn6UwN R1AkUTV74bU=

If you are using BIND, then you can check that your name server has identified and cached the new key with the following command.

1rndc secroots
2# Without the view name, this shows secroots for the default view only.
3cat /path/to/bind/working/directory/named.secroots
4secure roots as of 04-Sep-2017 21:58:43.872:
5Start view _default   Secure roots:
6./RSASHA256/20326 ; managed
7./RSASHA256/19036 ; managed

Note that the location of the file that rndc generates will depend on your operating system and particular configuration. If you aren’t sure, you can simply search for named.secroots.

Resources

The DNSOARC EDNS0 test server and explanation page is a good way of confirming your network’s ability to service modern DNS traffic. There is a testbed which will allow you to fully confirm the functionality of your systems. You can obtain the root KSKs manually. There are attestations and publicly verifiable signatures to assure you of the provenance of the keys on the website. IANA’s KSK rollover page is a little difficult to navigate (which is why I wrote this blog). But there’s still a lot of useful information contained in there.