Eventually we are going to have to roll the DNSSEC root key / trust anchor. There are many views about when we will have to do this, but eventually we will have to, because of improvements in factoring, desire to change to an new algorithm, political pressures, policy reasons or concerns about key compromise. For example, the DPS for the Root Zone KSK says Each RZ KSK will be scheduled to be rolled over through a key ceremony as required, or after 5 years of operation. (emphasis added)
Luckily RFC5011 - Automated Updates of DNS Security (DNSSEC) Trust Anchors describes a means for automated, authenticated, and authorized updating of DNSSEC "trust anchors". Unfortunately we don't really know how well this will work in practice, because it is unclear how many systems are configured to use RFC5011 style keyrolls, but also because we have not performed much testing of RFC5011 implementations.
This is somewhat of a scary position to be in - if the IANA rolls the DNSSEC root key, and there are systems that either do not implement RFC5011, or implement it incorrectly, these systems will believe that all DNSSEC signed responses are invalid ("bogus") and DNSSEC will break. This test infrastructure has been created to allow implementors and developers to test their RFC5011-style keyroll logic.
This infrastructure has been created with a fake root, and a fake DNSSEC trust anchor. This fake root contains two fake TLDs, '.invalid' and '.example'. These two fake TLDs each have a single TXT record at their apex, so that there is something to query. The fake trust anchor is rolled periodically, by a chunk of Python (keyroller.py).
RFC5011 specifies a number of timers - these are things like "The add hold-down time is 30 days or the expiration time of the original TTL of the first trust point DNSKEY RRSet that contained the new key, whichever is greater." Unfortunately, following these timers would make the test infrastructure unbearable slow, and so I simply ignore them - this seems to work just fine, but if you think you are running into issues with this, please contact me and I'll see about setting up a parallel infrastructure that honors the timers.
The keyroller is responsible for actually rolling the keys. It tries really hard to make sure that it always has at least two live keys (the active key and the new key) - the active key introduces the new key, and then eventually the old key gets revoked. This makes the new key the active key, it introduces a new key, and then gets revoked.
Please read RFC5011 for more details on how it actually works.
The keyroller creates new keys when needed, revokes old keys when they die, and maintains the chain of keys. It also writes information about the keys (key tag, filename, create time, revoked time, DS) and the current state (time, newest key, list of live keys, list of revoked (but not deleted) keys) in a database.
There is a Consistency Checker app that runs periodically and confirms that there is a valid key "path" from the first key, all the way to the current key. This should alert me if something went wrong (so far the only issues have been me manually futzing with stuff, like deleting all the records from the database!).
These is a fairly simple web interface that pulls information out of the database and presents it as HTML. One of the functions of this is to allow people using the test infrastructure to get the current key information, instructions on how to use the system, and example config files for various DNS implementations. Currently the only example is ISC BIND, but I'm planning on adding more - if you have a DNSSEC validating resolver and would like me to publish an example config for it, please send it over. I need to know where and in what format the managed keys go, and how to tell the resolver to use my fake root (go look at the BIND example, it's fairly clear).
This system written and maintained by Warren Kumari (firstname.lastname@example.org). Feel free to contact with any questions / issues.