RE: Seeking Advice on DNSSEC Algorithm Rollover
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. ___ 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
RE: Seeking Advice on DNSSEC Algorithm Rollover
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. ___ 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
Re: Seeking Advice on DNSSEC Algorithm Rollover
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 ___ 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
Re: Seeking Advice on DNSSEC Algorithm Rollover
On Sat, 2012-06-23 at 22:34 +, Spain, Dr. Jeffry A. wrote: 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. Before in-line signing existed, I rolled my keys from algorithm 5 to 8. I was thus using dnssec-signzone to perform the signing. I had also generated my own keys, both KSK and ZSK. ZSK's and KSK's up until then were running their own life-cycles independently from each other. I thought this 'independence' was good as DNSSEC events would happen spread around the year. 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) 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'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. I'm sure you'll post the results here! -- . . ___. .__ Posix Systems - (South) Africa /| /| / /__ m...@posix.co.za - Mark J Elkins, Cisco CCIE / |/ |ARK \_/ /__ LKINS Tel: +27 12 807 0590 Cell: +27 82 601 0496 smime.p7s Description: S/MIME cryptographic signature ___ 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
RE: Seeking Advice on DNSSEC Algorithm Rollover
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. 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
RE: Seeking Advice on DNSSEC Algorithm Rollover
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
RE: Seeking Advice on DNSSEC Algorithm Rollover
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 ___ 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
