On Apr 16 2010, Phil Mayers wrote:
>All,
>
>I'm about to submit the change request for signing our zones, and in our
>standard-form requests I'm required to submit a backout plan.
>
>What is the recommended/safe rollout/backout plan for signing a zone? I
>presume it goes something like this:
>
> 1. Insert DNSKEY records; wait for them to propagate (SOA TTL)
> 2. Sign the zone, increment the serial#, re-publish
You don't really have to separate those stages. If the non-existence of
DNSKEY records has been cached, that doesn't matter until you advertise
them (via DS in parent, DLV in dlv.isc.org, word of mouth, or whatever).
It's that advertising that should not take place until appropriate TTLs
have elapsed.
I'm not sure how you intend to actually do the signing - some signing
tools will manage the SOA serial for you.
You advise the administrators of your official slave servers that you
are doing this ... but of course you wouldn't forget to do that! :-)
> 3. Observe operation
This should of course include setting up a recursive nameserver with
your zone's KSK configured as a trust anchor, and exercising it to make
sure it is validating records from the zone correctly. ("ad" bit in
"dig +dnssec" responses, etc.)
Also very important at this stage: make sure the re-signing mechanisms
that refresh the RRSIG records before they expire are working properly.
Details of that depend on whether you are using periodic manual resigning
(with e.g. BIND's dnssec-signzone) or automated online resigning (as
BIND 9.6 or later can do for signed zones with allow-update != none).
> 4. If all is well, publish DLV record (or DS to parent)
>
>Assume this happens and *then* a problem is reported; how do I roll
>back? I note the TTLs in "dlv.isc.org" are 3600, so presumably it will
>take an hour (worst case) to "unpublish" a DLV.
De-registering the key at the dlv.isc.org website doesn't instantaneously
cause the zone to be rebuilt and pushed to its (many) official slaves
[or at least, it hasn't in the past] so that delay needs to be added
to the one hour TTL. In practice it's of the same order of magnitude.
There are no explicit promises in http://www.isc.org/files/dlv-policy.pdf
about this, though (and it's annoyingly out of date in minor respects
as well).
Similar considerations would arise with getting DS records removed
from a parent zone: an administrative delay, a delay in getting a
new version of the parent zone in service, and a delay determined
by TTLs until they expire from caches. Each of those is likely to
vary enormously depending on the parent zone administrator.
--
Chris Thompson University of Cambridge Computing Service,
Email: [log in to unmask] New Museums Site, Cambridge CB2 3QH,
Phone: +44 1223 334715 United Kingdom.
