[Opendnssec-develop] Re: Making PropagationDelay interactive

[Siôn Lloyd]

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
> actions?

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 
log messages.

> 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.

Sion