dnssec config sanity check

[Paul B. Henson]

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  |  henson at csupomona.edu
California State Polytechnic University  |  Pomona CA 91768