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