On 10/5/2011 10:25 AM, michoski wrote:
Your initial hope is what I missed comments on...
Me too; didn't get any "that's horribly broken because" or any "that looks good" feedback, guess I'll just have to review it a couple more times and hope for the best.
"It is recommended that the transition of a KSK from the published state to the ready state (introduction time) lasts for 45 days (RFC 5011, Automated Updates of DNS Security (DNSSEC) Trust Anchors). If the parent of the zone is signed, the recommended introduction time (SPARTA) is one week. The recommended period during which a KSK is retired before it is removed from the zone (retirement time) is four weeks. For the ZSK, the recommended introduction time is four days and the retirement time is two weeks." What values are other folks using?
I'm not sure why such a long retirement time is recommended, particularly for the ZSK which has no dependencies on getting a parent zone to update anything. For the KSK, you don't want to use it to sign anything until the parent has published the DS record, any old cached copies of that set without the new one have expired, you've published the DNSKEY record, and any old cached copies of that set have expired. For my case, I am publishing the KSK for an entire year before using it, so can't see any issues there. You don't want to remove a KSK until the parent has removed the corresponding DS record, cached copies have expired, and there are no longer any signatures floating around signed by it. My TTL is only 12 hours, so keeping it around for two weeks after I stop using it seems more than sufficient (and if for some reason there is an excessive delay getting the parent to remove the DS record, I can extend the publication further). For the ZSK, you don't want to sign anything with it after publication until you are sure there are no old cached copies of the set floating around without it. I'm going to publish the ZSK one month in advance of using it, so again don't see any issues. You don't want to remove it while there are potentially any cached signatures floating around that use it. Again with a TTL of 12 hours, two days seems like it should be a sufficient interval to wait. You don't want your signature lifetime to be too short, resulting in expired signatures before new ones are generated. My signature lifetime will be 35 days, with a forced signing at least once a month on the first of the month, along with a fresh signing anytime the backend data changes. So I don't see a scenario where my signatures would expire. The only edge case I can see that might cause a failure is if my primary server dies or there is an issue transferring the new zone to secondaries towards the end of the month. Hypothetically, if the underlying data doesn't change, and the zone was only signed on the first of the month, and an issue arises say the last week of the month, there is a case where it is possible my secondaries will have a copy of the zone that hasn't expired yet, but which does not have valid signatures. I'm willing to live with this possibility, as the likelihood of such a failure is low, and the likelihood it would be resolved quickly is high :). I guess if I missed anything at some point maybe Stephane Bortzmeyer will be contacting me to let me know my dnssec deployment is broken and asking what tool I'm using ;)... -- Paul B. Henson | (909) 979-6361 | http://www.csupomona.edu/~henson/ Operating Systems and Network Analyst | hen...@csupomona.edu California State Polytechnic University | Pomona CA 91768 _______________________________________________ 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
