Rolling, rolling, rolling…


In October 2017, ICANN are going to roll the key signing key in the root of the DNS.

If you’re not technical and don’t know what I just said, this post isn’t for you.

If, however, you run a validating recursive resolver, read on…

In October (the 11th to be exact), the key will roll and you’ll need to have done one of two things…

  1. Update your root trust anchor manually
  2. Check your resolver is RFC5011 compliant.

But first, a little…


So you know how DNSSEC works…

…you sign a zone. More specifically, you generate two keys, a key to sign the zone (ZSK), and a key to sign the keys (KSK). The zone gets bigger because for each record set, a signature is generated and added (RRSIG records). The public part of the keyset is also added to the zone (DNSKEY records). Some form of proof of non-existance is added (NSEC or NSEC3).

Next, once the keys and signatures have made it to all of the nameservers for the zone, you generate a delegated signer record (DS) from the KSK, and you publish that in the parent. The parent then signs the DS record, and hey presto, your chain of trust is made.

So, where’s the DS record for the root… To make this chain of trust work, resolvers that want to validate the DNSSEC chain of trust need a starting point in the root…

Your resolver has a trust anchor for the root. Depending on what you’re using for a resolver, this will either be the DS of the root KSK, or the public part of the KSK.

Your resolver will have this built in, but then, if configured correctly, will use an automatic mechanism to keep that key up to date and roll it when required.


RFC5011 defines how a resolver can automatically update a trust anchor for a zone.

So that you can check whether your resolver will follow this process, ICANN have an automated testbed for the KSK roll, which I encourage you to look at.

ICANN’s Automated Test

Each week, they create a new zone, and they sign it with a set of newly generated keys. Purposefully broken DS records are published in the parent zone, so that a normal validating resolver will SERVFAIL (because validation fails).

By adding a trust anchor to your resolver, the zone will validate.

If correctly configured, your resolver will now look for new key signing keys, and will observe them, and use them as per RFC5011.

So, lets take a look at this. Before I add a trust anchor, I can check that the zone doesn’t validate:

$ dig @::1 soa

; <<>> DiG 9.9.5-9+deb8u6-Debian <<>> @::1 soa
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 39100
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

; EDNS: version: 0, flags:; udp: 4096

;; Query time: 1908 msec
;; SERVER: ::1#53(::1)
;; WHEN: Mon Mar 20 13:22:57 GMT 2017
;; MSG SIZE  rcvd: 77

We can see in line 7, that we have a SERVFAIL response.

This server is running BIND. So, first we check that the server is configured manage keys using RFC5011:

options {
    dnssec-validation auto;

If you’re just adding this, don’t forget to rndc reconfig

Trust Anchor

Now, we need to add a trust anchor:


managed-keys { initial-key 257 3 8

This is added in your named.conf file.

Once again, don’t forget to rndc reconfig


If you’re running Unbound, then you can add the DNSKEY or DS records to a file in a location that Unbound can read and write to (so, somewhere like /var/lib/unbound/ and then add a auto-trust-anchor-file line in the server: section of your unbound.conf file.

cat /var/lib/unbound/ IN DS 3934 8 1 47AA8AAF4D75B3D9C58448F241F793EBC4977821 IN DS 3934 8 2 0D27F2E6EA9CA548F1896A71FB07CED86074D3462F2A720D6177F3C5CEC15F0D

Note; the file doesn’t look like this once you’ve told Unbound about it, as it uses the file to store metadata related to the RFC5011 process.

    auto-trust-anchor-file: "/var/lib/unbound/"

After adding those, you’ll want to unbound-control reload to pick up the changes.


$ dig @::1 soa

; <<>> DiG 9.9.5-9+deb8u6-Debian <<>> @::1 soa
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30413
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 3

; EDNS: version: 0, flags:; udp: 4096

;; ANSWER SECTION: 60 IN	SOA 1489968062 3600 600 86400 60



;; Query time: 428 msec
;; SERVER: ::1#53(::1)
;; WHEN: Mon Mar 20 13:44:24 GMT 2017
;; MSG SIZE  rcvd: 181

This time, we can see that on line 7, we have a NOERROR response, and on line 8, we can see that we have ad in the flags.

What’s next…

Now, we wait. The next step is that ICANN’s automated test lab will generate and publish a new KSK into the zone on the 19th.


One thought on “Rolling, rolling, rolling…

  1. Pingback: A New Key… – Karl's Little World

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s