>> 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. Jeffry A. Spain Network Administrator Cincinnati Country Day School _______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
