On 10/3/2011 6:31 PM, Mark Andrews wrote:
Don't ASSUME that the DS will be published in time. Build checks into your proceedures from the beginning. e.g.Publish and activate July 1. Change DS records July 8. Check that DS is published July 15 and set inactivate and deletion dates if and only if new DS is published to August 1 and September 1 respectively. If the DS is not publish chase up with parent and recheck the next day slipping inactivate and deletion dates for a day for each day the DS publication date is past July 15.
Other than the (regrettably still manual) update of the DS in the parent zone via the registrar, everything else is automated. I don't think we'll assume the registrar will do the right thing, but rather than waiting until verifying they have and then doing manual things, I think I'd rather have the automated process take care of things without intervention, and then only have to manually step in and tweak if the registrar doesn't update in a timely fashion. Call me optimistic :).
Why would I delay a week between publishing the new KSK and updating the DS records? With a TTL of only 12 hours, it seems a delay of no longer than that would be required (assuming the new zone was successfully transferred to all secondaries).
I initially assumed it wouldn't matter if there was a DS entry in the parent zone for a KSK that was no longer in use and not published, but it seems in that scenario a resolver might consider the zone bogus and fail it. From what I've read, it sounds like it shouldn't, but better safe than sorry. The update is removing a key no longer in use, and adding a key that won't be used for another year. The new DS entry for the new key won't really be needed until that year has passed unless a key compromise requires an early rollover. The old DS entry shouldn't need to be around for any more than the 12 hour TTL that clients might still have signatures from the old key in their caches. Operationally, I'll probably update the DS entries the day after the new key is generated, and with the current 1 day+ latency the registrars seem to be displaying, the DS cut over will happen probably 2-3 days after the key cutover. If the registrar hasn't updated within 14 days, I'll need to tweak the deletion date for the old key to prevent any broken resolvers from failing. The key actually being used has already existed in the parent zone for the last year, so verifying the current signatures shouldn't be an issue even if the registrar flakes out.
Thanks... -- 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
