dnssec config sanity check
Paul B. Henson
henson at acm.org
Tue Oct 4 22:30:14 UTC 2011
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
More information about the bind-users
mailing list