Seeking Advice on DNSSEC Algorithm Rollover

[Spain, Dr. Jeffry A.]

I'm experimenting with rolling over my DNSKEYs from algorithm 7 to 8. The Bv9ARM doesn't discuss this procedure explicitly as far as I can tell, but section 4.9 presents some clues. I'd like to ask the experts on this list if the following procedure might accomplish an algorithm rollover cleanly.

The zones on my server (BIND 9.9.1-P1) are set up as slaves for inline signing. Unsigned zone data is received from a stealth master via inbound zone transfer. Each zone is configured for "auto-dnssec maintain" and "inline-signing yes". A series of ZSKs and KSKs are stored in key directories by zone with timing metadata set to keep two ZSKs and KSKs published and one active. There is no "update-policy" statement in place. Both the unsigned and signed zone files are in raw format by default. The dnssec-loadkeys-interval is not specified and so defaults to 60 minutes.

First of all, the procedure for adding the new algorithm 8 seems simple, and I already did this successfully:

a) Create the required algorithm-8 ZSKs and KSKs and place them in the key directories, carefully setting ownership and permissions.
b) "rndc sign <zone>" for all zones or wait for dnssec-loadkeys-interval to elapse.
c) After verifying that the new DNSKEYs, RRSIGs, and NSECs are in place, publish the required algorithm-8 DS records in the parent zones.

The procedure for removing the old algorithm 7 keys seems trickier. I believe nsupdate will be required, and so "update-policy local" will need to be added to the configuration of each zone followed by "rndc reload". I think the option "dnssec-secure-to-insecure yes" may also need to be configured for this to work:

a) Remove the algorithm-7 DS records from the parent zones.
b) Wait for the maximum TTL to expire. From inspection this varies among gTLDs and may be as long as 24 hours.
c) Remove all the algorithm 7 keys from the key directories.
d) Using nsupdate, delete all of the algorithm 7 DNSKEYs from each zone. All algorithm-7 RRSIGs and NSECs should be automatically removed when the updates are sent.

I am concerned that step c) may cause a problem if named decides to carry out any signing activities prior to the completion of step d). One could examine all the RRSIGs and confirm based on sig-validity-interval that no signing activity is immanent, but that seems tedious. One could also temporarily change auto-dnssec from maintain to allow, but that also seems cumbersome if there are lots of zones.

Perhaps another rndc command could be developed to help with this. For example, "rndc pause-signing <zone>" might disable signing activities temporarily until a subsequent "rndc sign" command was sent, or as a safety valve, until the next dnssec-loadkeys-interval elapsed. The dnssec-update-mode option seems to incorporate this idea, but it must be statically configured, and is said to work only for master zones (as opposed to the inline-signed slave zones that I have).

I would be grateful for your additional thoughts on this. Thanks. Jeff.

Jeffry A. Spain
Network Administrator
Cincinnati Country Day School

[Alexander Gurvitz]

Hello.

I don't think that bind trying to sign with non-existent key will do any harm - probably just warning.

But it's simpler - change metadata of the key - set deletion time to the time you want the key to be deleted (like DS deletion time+TTL).

Bind with auto-dnnsec allow re-reads the metadata and should remove the key and all the signatures at that time.

You don't need nsupdate nor update-policy for that.

Regards,

Alexander Gurvitz,

net-me.net

[Spain, Dr. Jeffry A.]

> I don't think that bind trying to sign with non-existent key will do any harm - probably just warning.
> But it's simpler - change metadata of the key - set deletion time to the time you want the key to be deleted (like DS deletion time+TTL).
> Bind with auto-dnnsec allow re-reads the metadata and should remove the key and all the signatures at that time.
> You don't need nsupdate nor update-policy for that.

Thanks very much. My experience with changing the timing metadata or removing the key files is that named issues a warning like the following:
zone <zone>/IN: Key <zone>/<algorithm>/<key tag> missing or inactive and has no replacement: retaining signatures.
In this circumstance none of the RRSIGs or NSECs are removed. They sit there indefinitely even after the RRSIGs expire.
Best regards, Jeff.

[Spain, Dr. Jeffry A.]

> I discovered that if there was not at least one KSK and ZSK of the same algorithm, dnssec-signzone would fail. If one goes with defaults, KSK life of one year and ZSK of one month, effectively to roll a key algorithm and without forcing the roll-over by removing all the old key/algorithm at the same time, you have to wait for a KSK to 'expire' then add a new algorithm key pair together. As soon as the last old algorithm KSK expires, there must no longer be any old algorithm ZSK's left, but old algorithm ZSK's must be around until this event.
> That is - at the time of roll-over - you have a KSK/ZSK pair using the old algorithm and a pair using the new algorithm, obviously with appropriate DS's in the Parent.
> (That should make sense)

That sounds like it is worth a try. My experience is that when keys from only one algorithm are in place and those keys go inactive, then named issues warnings "Key <zone>/<algorithm>/<hey tag> missing or inactive and has no replacement: retaining signatures", and the RRSIGs and NSECs are not removed. Maybe with the second algorithm's keys already in place and the zone signed by them, the behavior will be different. I will report back on this.

> So, if you only have a very few signed zones, its possibly easier to resign them from scratch, or force a roll-over. (Avoid the pain!) If you re-do everything at the same time - then DNS signing events may no longer be scattered around the year - maybe not a good thing.

I'm pretty sure that I can resign from scratch as follows on the inline signing slave:
1) Remove the key files from the old algorithm.
2) Remove the zone files, both signed and unsigned.
3) Increment the SOA serial number on the unsigned zone on the stealth master to something greater than the SOA serial number of the signed zone on the inline signing slave.
4) Reload the zone on the inline signing slave.
I will also report back on this.

> I'd expect in-line signing to be of a similar nature unless algorithm 7 and 8 keys can as such 'speak for each other'.
> My advice, test mixing old and new algorithm keys by signing with dnssec-signzone and presume the same rules exist for in-line signing too.
> I'd look for a solution that 'upgrades' a zone to using a new Key algorithm at the scheduled time of a KSK roll-over.

Based on testing since my initial post, I have determined that any solution requiring the use of nsupdate isn't going to work. In my scenario where the zones are slaves transferring data from a stealth master and doing inline signing, i.e. the bump-in-the-wire concept, named won't even start with "update-policy local" in the configuration. It considers "update-policy local" a configuration error in zones of "type slave".

As I think about this issue more, it seems like a job for rndc. For example, I would like to suggest that there be a command "rndc signing -algclear <algorithm number> <zone>", which would immediately remove DNSKEY, RRSIG, NSEC(3), and any other records pertaining to <algorithm> from <zone>. It would be used in the following procedure after the keys for the new algorithm are already in place and the zone has been signed by them:

1) "rndc signing -pause <zone>" (to pause temporarily "auto-dnssec maintain" signing activities). In my previous post I had suggested the syntax "rndc pause-signing <zone>" but this seems more consistent with existing "rndc signing" syntax.
2) Remove the key files belonging to the old algorithm.
3) "rndc signing -algclear <old algorithm number> <zone>"
4) "rndc sign <zone>" (to immediately resume "auto-dnssec maintain" signing activities) or wait for dnssec-loadkeys-interval to elapse.

> I'm sure you'll post the results here!
I will. Thanks again for your input. Jeff.

[Spain, Dr. Jeffry A.]

>> I discovered that if there was not at least one KSK and ZSK of the same algorithm, dnssec-signzone would fail. If one goes with defaults, KSK life of one year and ZSK of one month, effectively to roll a key algorithm and without forcing the roll-over by removing all the old key/algorithm at the same time, you have to wait for a KSK to 'expire' then add a new algorithm key pair together. As soon as the last old algorithm KSK expires, there must no longer be any old algorithm ZSK's left, but old algorithm ZSK's must be around until this event.
>> That is - at the time of roll-over - you have a KSK/ZSK pair using the old algorithm and a pair using the new algorithm, obviously with appropriate DS's in the Parent.
>> (That should make sense)

> That sounds like it is worth a try. My experience is that when keys from only one algorithm are in place and those keys go inactive, then named issues warnings "Key <zone>/<algorithm>/<hey tag> missing or inactive and has no replacement: retaining signatures", and the RRSIGs and NSECs are not removed. Maybe with the second algorithm's keys already in place and the zone signed by them, the behavior will be different. I will report back on this.

This appears to have worked perfectly. Again I started from a position where there were two sets of keys in place, one for algorithm 5 and one for algorithm 8, and the zone was signed by both. For each algorithm, I had a sequence of nine ZSKs with timing metadata set so that a key rollover would occur every 90 days for a two-year period. I had two KSKs for each algorithm: one published and active, the other published and not yet active.

I processed the keys for algorithm 5 (the one to be removed) as follows using dnssec-settime:
1) For keys with a deletion date in the past, do nothing.
2) For keys currently published but deactivated, set the deletion date to earlier today (20120624).
3) For keys currently published and active, set the inactive and deletion dates to earlier today.
4) For keys currently published but not yet active, set the inactive and deletion dates to earlier today.
5) For keys with a publish date in the future, do nothing.

Immediately afterwards I ran "rndc loadkeys <zone>" and for good measure "rndc sign <zone>", although perhaps only one of these was really necessary. An AXFR immediately afterwards showed no DNSKEYs or RRSIGs remaining from algorithm 5.

I think I'm good to go with this procedure. I think the proposed "resigning from scratch" procedure is less desirable since it would involve more administrative overhead and more processing by named, so I will not test that further at this point. I'll let my previously suggested enhancements to rndc stand as an alternative.

Thanks. Jeff.

[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.

----------

[Tony Finch]

Spain, Dr. Jeffry A. <spa...@countryday.net> wrote:
>
> My experience with changing the timing metadata or removing the key
> files is that named issues a warning like the following: zone <zone>/IN:
> Key <zone>/<algorithm>/<key tag> missing or inactive and has no
> replacement: retaining signatures. In this circumstance none of the
> RRSIGs or NSECs are removed. They sit there indefinitely even after the
> RRSIGs expire.

If I remember correctly, that was because you removed the keyfile rather
than just updating the timing metadata. Try updating the timing data and
leaving the keyfiles in place until after BIND has acted on the deletion
date.

Tony.
--
f.anthony.n.finch <d...@dotat.at> http://dotat.at/
Forties: Northwesterly 4 or 5, occasionally 6 in east. Slight or moderate,
occasionally rough later. Mainly fair. Moderate or good.

[Spain, Dr. Jeffry A.]

>> My experience with changing the timing metadata or removing the key
>> files is that named issues a warning like the following: zone <zone>/IN:
>> Key <zone>/<algorithm>/<key tag> missing or inactive and has no
>> replacement: retaining signatures. In this circumstance none of the
>> RRSIGs or NSECs are removed. They sit there indefinitely even after
>> the RRSIGs expire.

> If I remember correctly, that was because you removed the keyfile rather than just updating the timing metadata. Try updating the timing data and leaving the keyfiles in place until after BIND has acted on the deletion date.

I did some additional testing over the weekend. Removing the key files without updating the timing metadata definitely causes this problem. Updating the timing metadata such that the inactive date is in the past and the deletion date is in the future also causes this problem. The key to success appears to be updating the timing metadata such that the inactive and deletion dates are both in the past. I still want to test this where there are no keys present for a second algorithm, i.e. a secure to insecure transition. Thanks. Jeff.