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