[Opendnssec-develop] Re: Making PropagationDelay interactive
sion at nominet.org.uk
Thu Jul 26 08:15:23 UTC 2012
On 10/07/12 11:09, Rick van Rein wrote:
> Hello Siôn,
> We're going to automate DS-uploads; as usual we'll be quite public
> about how this can be done. But I have a question, because we're
> assuming 2.0-ish behaviour that we'd like to patch into 1.x. We
> don't know the Enforcer completely, so here are some questions.
> 1. Are there no exceptions to this KSK maturation path?
> Generate -> publish DNSKEY -> Ready -> publish DS -> Active
As Matthijs has pointed out, not in the current enforcer code (apart
from standby KSKs).
> 2. Is it possible to set a future time in the "ready" column of
> dnsseckeys? If we do that, will the key automatically go to the
> ready state at some time after that setting, and pickup on further
This is not currently possible as the transition times are recalculated
whenever the enforcer runs.
One exception is the retire time of a key that was imported... I only
mention this to say that there is a (partial) implementation of this
which could be extended if it is really needed. It is not a small amount
of work though, mostly because of the testing that would be needed.
> We'd prefer not to rely on some magic value of PropagationDelay, but
> wish to actually check until the authoritatives pickup on a new DNSKEY
> set, and if it does, report that back to the Enforcer; when that
> happens, we would want it to wait for TTL(DNSKEY) + PublishSafety
> before we would be hinted to publish the DS to the parent. This
> wait could be done by setting the "ready" timestamp to the current
> time plus the wait time.
> This enables elegant / simple scripting outside the Enforcer,
> mostly limited to the details of the local setup, and leave all
> the timing complexity and generic issues inside the Enforcer.
> And, it'd be "2.0 ready" scripting, so people can easily upgrade.
I have thought about this from time to time... "Why guess at the zone
propagation when we can actually look for it".
My idea was along the lines of "set the propagation delay to zero and
ignore the log message indicating that the ds-seen should be issued
until we know that it should be from observation".
This is possible now, but not nice as you need to deliberately ignore
> If you think this makes no sense then please let us know :)
I think that a nice, properly integrated, solution is too much work to
make the 1.4 release; and so would probably need to wait for the
enforcer-ng. If it is really needed for the 1.4 code then we could look
at scheduling it for 1.4.X.
Hmm, maybe I should have written this on jira rather than email? Oh well.
More information about the Opendnssec-develop