Seeking Advice on DNSSEC Algorithm Rollover

[Spain, Dr. Jeffry A.]

I propose the following addition to the Bv9ARM, and request review and comment by the experts on this list.

----------

4.9.14 DNSKEY Algorithm Rollover

>From time to time new digital signature algorithms with improved security are introduced, and it may be desirable for administrators to roll over DNSKEYs to a new algorithm, e.g. from RSASHA1 (algorithm 5 or 7) to RSASHA256 (algorithm 8). The algorithm rollover must be done with care in a stepwise fashion to avoid breaking DNSSEC validation.
	
As with other DNSKEY rollovers (sections 4.9.5 - 4.9.7), when the zone is of type master, an algorithm rollover can be accomplished using dynamic updates or automatic key rollovers. For zones of type slave, only automatic key rollovers are possible, but the dnssec-settime utility can be used to control the timing of such.

In any case the first step is to put DNSKEYs using the new algorithm in place. You must generate the K* files for the new algorithm and put them in the zone's key directory where named can access them. Take care to set appropriate ownership and permissions on the keys. If the auto-dnssec zone option is set to maintain, named will automatically sign the zone with the new keys based on their timing metadata when the dnssec-loadkeys-interval elapses or you issue the command rndc loadkeys zone. Otherwise for zones of type master, you can use nsupdate to add the new DNSKEYs to the zone. This will cause named to use them to sign the zone. For zones of type slave, e.g. on a bump-in-the-wire inline signing server, nsupdate cannot be used.

Once the zone has been signed by the new DNSKEYs, you must inform the parent zone and any trust anchor repositories of the new KSKs, e.g. you might place DS records in the parent zone through your DNS registrar's website.

Before starting to remove the old algorithm from a zone, you must allow the maximum TTL on its DS records in the parent zone to expire. This will assure that any subsequent queries will retrieve the new DS records for the new algorithm. After the TTL has expired, you can remove the DS records for the old algorithm from the parent zone and any trust anchor repositories. You must then allow another maximum TTL interval to elapse so that the old DS records disappear from all resolver caches.

The next step is to remove the DNSKEYs using the old algorithm from your zone. Again this can be accomplished using nsupdate to delete the old DNSKEYs (master zones only) or by automatic key rollover when auto-dnssec is set to maintain. You can cause the automatic key rollover to take place immediately by using the dnssec-settime utility to adjust the timing metadata on all key files associated with the old algorithm. There are five cases:
1) For keys with a deletion date in the past, do nothing.
2) For keys currently published but deactivated, set the deletion date to sometime in the past.
3) For keys currently published and active, set the inactive and deletion dates to sometime in the past.
4) For keys currently published but not yet active, set the inactive and deletion dates to sometime in the past.
5) For keys with a publish date in the future, do nothing.

After adjusting the timing metadata, the command rndc loadkeys zone will cause named to remove the DNSKEYs and RRSIGs for the old algorithm from the zone. Note also that with the nsupdate method, removing the DNSKEYs also causes named to remove the associated RRSIGs automatically.

Once you have verified that the old DNSKEYs and RRSIGs have been removed from the zone, the final step (optional) is to remove the key files for the old algorithm from the key directory.

----------


Jeffry A. Spain
Network Administrator
Cincinnati Country Day School