DNSSEC uses keys with which it signs DNS records, and there is a school of thought which suggests DNSSEC keys should be rolled (i.e. re-created) every once in a while. The recommended frequency for doing this is specified in DNSSEC Operational Practices, Version 2 with additional information in DNSSEC Key Rollover Timing Considerations (draft). Whether or not you want to roll keys is a matter of taste (and/or paranoia?). How often have you rolled your SSH host keys? (And I don’t mean unplanned rolling by, say, re-installing the host without backing up and restoring its keys). How often has the root DNSSEC KSK key been rolled? Let’s look at the root trust anchor which was published on the 15th of July 2010:
Now let us look at the current DS of the root’s KSK:
Notice a difference in the digest? No, I don’t either. In other words, the root KSK has never been rolled, but ICANN is seeking volunteers for the DNSSEC Root KSK Rollover Plan Design Team…
The relationship between a DNSSEC-signed zone (e.g.
example.org) and its
parent zone (e.g.
org) make rolling DNSSEC key-signing keys (KSK) difficult:
when I renew keys for
example.org I have to submit the public DNSKEY or its
hashed DS record to the parent (
org); they add / replace that record for my
example.org in their zone and re-sign
org creating a chain of trust from
example.org. This of course means I can’t just roll my KSK at will;
if I don’t interact with my zone’s parent, my zone becomes insecure and thus
bogus for validating resolvers. DNSSEC basically consists of islands of trust;
keys in a zone which are validated by trust anchors in other zones; this is
comparable to how delegation works.
In a test environment or in private DNS networks, DNSSEC is easy: I can create, change, roll, whatever DNSSEC KSK keys at my whim, copy the relevant DS records to parent zones, re-sign and all is fine. But can’t this be automated?
RFC5011, Automated Updates of DNS Security (DNSSEC) Trust Anchors, specifies a mechanism by which trust anchors can be deployed automatically via the DNS. A resolver periodically queries the DNS to determine whether a new DNSKEY has been published; if so, and if it can be validated by an existing trust anchor, it’s retrieved and used as a future trust anchor for that zone. RFC 5011 works because new keys are signed by old keys and thus the chain of trust is maintained.
The upcoming version of OpenDNSSEC will also have support for RFC 5011. (If you’re new to OpenDNSSEC, read an earlier post on it and I highly recommend you print out this excellent document created by AFNIC.)
What I basically do, is specify RFC 5011 for the KSK keys in my
It’s also important to note the following:
- Your configured
DelegationSignerSubmitCommandwill not be invoked for RFC 5011 keys.
- Keys jump from
active, bypassing the
ds-seencommand should not be invoked on these keys; in fact you probably won’t see
waiting for ds-seenas a status at all.
RFC 5011 support in OpenDNSSEC is very new and it is, in theory, difficult to test because of the waiting periods involved between rolls. The good folk at NLnetLabs chose to implement a feature which you compile in when building OpenDNSSEC and which you do not use in production! I can set an environment variable to define a particular point in time; with this, rolling a KSK becomes trivial:
So, how do I test this other than looking at the DNSKEY records published and signed by OpenDNSSEC in the zone?
OpenDNSSEC signs a test zone (here:
jp.aa) and notifies NSD which transfers
the zone in and serves it authoritatively. On the other side I have Unbound
and BIND configured as recursive, validating resolvers to answer incoming
A utility I’ve found very helpful in keeping track of keys as they are created and revoked is Stéphane Bortzmeyer’s key-checker which uses a small SQLite3 database to keep track of new keys. (Read the paper entitled Monitoring DNSSEC zones: what, how, and when?.)
I launch key-checker as
or via cron, etc. It probes the specified DNS server for DNSKEY records for the specified zone and mails me reports:
I keep the reports in a mailbox and use that as an archive of what happened when.
Unbound has a trust anchor configured which I obtained from
ods-ksmutil key export --zone jp.aa --keytype ksk and placed in the file
Some time after the successfull KSK rollover, Unbound successfully obtained the new anchor and stored it:
Note how the comments show the REVOKED key; the key’s flags (385) have bit 8 set which mean’s it has been revoked.
Unfortunately, my experiments in doing the same for BIND haven’t been particularly fruitful and I may now (a month later, on 2015-02-19) tell you that they culminated in CVE-2015-1349, so I will have to do this again. In theory, setting this up is just as easy as doing so for Unbound: I just configure a
managed-keys stanza in
named.conf, reconfigure, and that’s it.
I’m too impatient: since I can’t seem to be able to force BIND to “go, on, look now to see if there are new DNSKEYs, mate!”, I have to wait until it does its thing. Also, I’m currently chasing down another little problem …
I have actually seen BIND write a revoked key (385) into
I haven’t been able to yet actually test whether validation continues working.
BIND operates as I expected it to after the rollover.
If you want to do your own experimenting with a “fake” DNS root zone which rolls its keys (currently every 90 minutes), Warren Kumari’s Keyroller is what you need, and Jakob Schlyter has created an associated toolset which downloads the Keyroller key, formats it, and launches either BIND or Unbound on it.