[Opendnssec-user] Unexpected DS state transition UNSUBMITTED to SUBMITTED (v 2.1.5)

[Berry van Halderen]

On 2021-06-29 11:11, Havard Eidnes via Opendnssec-user wrote:
>> It is not clear when one should execute 'ods-enforcer key ds-seen'.
>> Is that as soon as the DS record first appears in the parent zone?
> 
> In my setup I use a small perl script which checks that all the
> publishing name servers for the parent zone respond with the newly
> published DS record before signaling "key ds-seen".
> 
> I also think that the <PublishSafety> timer setting plays into when
> OpenDNSSEC considers doing the next state transition.  The
> documentation is, though, a little vague on this point; it says:
> 
>    <PublishSafety> and <RetireSafety> are the publish and retire
>    safety margins for the keys. These intervals are safety margins
>    added to calculated timing values to give some extra time to cover
>    unforeseen events, e.g. in case external events prevent zone
>    publication.
> 
> It's not entirely clearly expressed at which time or at which event
> these times are added, and what OpenDNSSEC thinks it is free to do
> when this timer expires.

Yes, this is indeed the additional time that is being waited (to
be more precise, additional time taken subtracted from the time
that the roll should be completed).  The role of the
PublishSafety and RetireSafety is to allow for a certain clockskew
on the internet.  If all clocks would run second precisely, this
parameter could be 0.

Also the other comments in this thread are basically correct.  When
all timings are set (correctly) in the policy KASP, then the only
operator interaction should be the actual placing of the DS record
in the parent zone (as this is mostly a non-standard way), and
because we can't know when the DS has actually been placed into
the parent zone, the operator should indicate when at least one
nameserver has seen the DS record.

Tying into the next paragraph, there is no need to ever build
in you own "wait" times, or to take into account any TTL.  This
is what OpenDNSSEC enforcer is meant for.

I do also agree with Havard that I should spend time on the 
documentation.
Much of the documentation is still 1.4 based, like the submitted
state which isn't relevant anymore.  The reason you can see
see traces of this in the output is to be backwards compatible on
an output level, but this will be dropped in future.
The documentation currently often tries to be multiple things, well
it's a wiki.  Both reference, how-to, background and operational
notes.

BR,
\Berry

>> Or should one wait an additional DS TTL so it expires from caches?
>> I suspect it is the former, but in either case it is not clear what
>> is the point of specifying the parent DS TTL in the policy.
> 
> You're probably talking about the <TTL> setting in the <DS> section of
> the <Parent> section?  Typically, the parent zone admin sets the TTL
> for the DS records it publishes based on its own policy.  Apparently,
> OpenDNSSEC uses this timer to calculate the timing of its own actions.
> But again, the documentation is a little vague -- when talking about
> the SOA timers "used by KASP in its calculations" is all it says.
> 
> This part of the config glosses over the fact that there may be more
> than one parent zone for the zones under OpenDNSSEC's handling, and
> whether the timers configured in this section should be the largest in
> the collection of parent zones.
> 
> Best regards,
> 
> - Håvard
> _______________________________________________
> Opendnssec-user mailing list
> Opendnssec-user at lists.opendnssec.org
> https://lists.opendnssec.org/mailman/listinfo/opendnssec-user