DNSSEC

It is one thing to sign a zone and publish an RRSIG next to each DNS record; it is quite another to integrate the signing process with the parent’s. This is necessary however, to complete the chain of trust that reaches from the root zone . down to your individual RRSIG records.

Although not all parents follow the same procedures, the general idea usually is that you upload a DS or DNSKEY over EPP. To facilitate various rollover procedures, it is often possible to manage multiple such DS/DNSKEY records over EPP. As always with DNSSEC, the big question is when a certain change may be made without risking domain downtime due to cached older results.

Our Approach

Most DNSSEC approaches take the shape of a step-by-step procedure, intended to ensure that all the caches can follow the changes, and thus that all parties on the Internet always see the zone in a valid state.

Another approach is to represent these various states of the zone inside the system, and have the data evolve through that model. This is the approach taken here.

We see the KSK set as a set of DNSKEY records that starts at one point, and then rippples through a number of stages, each time subject to conditions or timers, until it has spread to the end and reaches a stable state. Whenever two subsequent stages have a different KSK set, then apparently some work needs to be done.

We recognise the following levels of progress, and conditions to progress to them from the foregoing stage:

Implementation

We have implemented this approach in a cron-job that can run as often as we like; any waiting is implemented independently. The state of a parent relationship is stored in a data directory, such as /var/opendnssec/parenting/ as a series of files, one per state. The files hold the DNSKEY set that is taken into account.

We treat a set as a whole. Specifically for timing issues, we look at the timestamp of the last change on the files, so on the KSK set. This means that one theoretic problem could occur: if a zone keeps on changing, it would never be found silent for TTL+1h and so it would never advance into the parent. This is not likely to occur in practice.

When uploading over EPP, it is usually not possible to offer a new DS set or DNSKEY set; instead, separate add/remove commands are usually required. To that end, we download the old set and calculate the changes necessary to get to the desired new state.

Download code

Code of the engine is available as a free download, without any guarantees or maintenance promises; we simply offer it in the hope that it is useful.

You will need to integrate it with your EPP workflow, as that is not included; it is usually very personal to an environment. Our code refers to a “registry_shell” that must implement a few simple EPP commands, and all you need to do is hook those up to your EPP code:

* socket = connection ( (‘hostname’, port) )
* hello (socket)
* login (socket)
* currkeys = eppkeys (socket, zonestr)
* update_keys (socket, zonename, currkeys, newkeys)
* logout (socket)

Chances are that eppkeys() and update_keys() are new calls, as they may be your first encounter with DNSSEC in EPP. Please see your parent’s EPP manual regarding its implementation in their registry. If you have multiple parents, you will need to make a slight generalisation of the script, but at least the difficulties of the workflow will have been resolved for you.