Considerations about Time To Live

Written by Rick van Rein in category: Architecture, Timing, Users

Click for complete diagram

OpenDNSSEC is much more dependent on proper timing than plain DNS, mainly because of the regular rollover of keys. The last thing we would want is a secure resolver which has parts of a secure domain, but not enough to validate it properly. What this means is that a lot of care must go into the design of timing, and especially the TTL parts of DNS records.

If you care for a state diagram, please click on the snippet image on the right.

To get a zone signed, you therefore need to go through a number of stages, and insert the proper delays between steps:

  1. To go from unsigned state to having the zone signed, we basically run the zone through OpenDNSSEC, and wait until a signed zone pops up at the other end. We are cautious however; “at the other end” means that all authoritative name servers for a zone have updated to the signed zone.
  2. We now proceed to publish the DS in the parent zone immediately. There is no danger of caches missing out on the signed state, as the cache should not have been asked for DNSKEY or RRSIG records before the DS record is public. And since the DS is not published before all our authoritatives have updated to the signed zone records, we are certain that the answers to DNSKEY or RRSIG will be available to caches.
  3. We now wait until the parent has published the DS in all its authoritative name servers. At this time we call the zone verifiable, because it is now possible for clients to validate the zone. But we do not report this state back to the zone owner, but our responsibility to ensure continuous proper state of the zone does start at this point. Since we signed through OpenDNSSEC, the management of this state is easily delegated to its component KASP Enforcer.
  4. We are still not completely satisfied when a zone is verifiable; caches may hold the parent’s NS records without matching DS. So after the DS is published, we wait the maximum caching time for the records in the signed zone. Only after that timer expired, will we announce to the zone owner that the zone is now verified.

While in this verified state, we can rest assured that the zone is either properly signed, or drops off the Internet. As said above, we now rely on OpenDNSSEC to manage the zone for us, by keeping signatures fresh and the zone signed and available. If the signer stops for whatever reason, we now need to repair it soon, before zone signatures start to expire. This is why we have setup a redundant architecture.

In the verified state, we can edit the zone as always. Added zones will be included, OpenDNSSEC will pick them up and sign them in a newly published zone version. If we’d care to move to another registrar, we would have to add a DNSKEY for the new registrar’s public key; if we’d move a zone to our service, we might have to do the opposite, and/or publish the old registrar’s DNSKEY for some time. And if we decide to rollover the Key Signing Key, we’d have to communicate with the parent zone to replace the DS stored for our zone.

Reverting the zone back to unsigned state is a similar exercise, but in the opposite order. This too must be done with care, because dropping signatures too soon would make the domain disappear from the Internet from the perspective of caches that still expect a signed zone. So here are the steps we follow:

  1. The first thing we do is retract the DS from the parent. This can be done without further ado, because this breaks the chain on the top side, in a way that creates a signature that our zone opts out from DNSSEC. Once all authoritatives of the parent have dropped the DS record, we assume to have a retracted zone.
  2. We are not ready at this point to tell OpenDNSSEC to stop signing the zone; caches may still hold the old DS and may still rely on signed zones, so OpenDNSSEC is still responsible for keeping the zone signed. We now wait until all zones have expired any remaining DS records before we consider to have arrived at an insecure zone.
  3. Since no cache is now relying on signed zone records, we can remove the signatures that OpenDNSSEC created. In short, we revert to publishing the unsigned zone, leading it into the unsigned state from which it can be signed once again if its owner is so inclined.

It should be clear that publishing signed zones takes some effort, and is not to be taken lightly. On the light side though, it is perfectly possible to automate the procedure and just sit back and wait while computers roll through the scenario.

Respond

*