Re: [DNSOP] New draft on delegation revalidation

[Shumon Huque <[e-mail]>]

On Wed, Apr 22, 2020 at 4:48 PM Patrick Mevzek <[e-mail]>
wrote:

> On 22/04/2020 14:32, Shumon Huque wrote:
> > Based on history to date, it seems to be rather intractable, but I would
> > love to be proven wrong. The interfaces that registrars use to update
> > delegation records in the registries don't even offer any TTL
> > configuration option that I've seen (even if the registries were willing
> > to support it). Does the EPP DNS mapping even support setting TTL?
>
> I am not sure what you refer to by "EPP DNS mapping".
>

I meant the use of EPP for provisioning DNS objects. EPP is a general
purpose protocol, no? And I think it's use for specific applications is
called a "mapping". But my knowledge of EPP is quite meager, so I'd
be happy to be corrected. Thanks for chiming in with the rest of the info!

In EPP world there are host objects (or host attributes).
> Those are created by the registrar, in the registry system, and the
> registry will use them to publish NS records, and potentially glues.
>
> Those objects have name, IP addresses and a few extra meta data but
> nothing about TTL.
> And when you update domains for new NS you just specify the host object
> IDs you want to use (which are in fact there name). For registries using
> hosts as attributes instead you then there provide also glues, if
> needed, but nothing more.
>

Yeah, that was what I thought. I just wasn't sure whether some EPP TTL
setting extension had been proposed or developed.


>
> To give another data point, that goes into your direction, there is a
> secDNS extension, that registrars uses to pass DS/DNSKEY materials to
> registries, for publication.
>
> It has the following specified:
>
>         An OPTIONAL <secDNS:maxSigLife> element that indicates a
>          child's preference for the number of seconds after signature
>          generation when the parent's signature on the DS information
>          provided by the child will expire.  A client SHOULD specify the
>          same <secDNS:maxSigLife> value for all <secDNS:dsData> elements
>          associated with a domain.  If the <secDNS:maxSigLife> is not
>          present, or if multiple <secDNS:maxSigLife> values are
>          requested, the default signature expiration policy of the
>          server operator (as determined using an out-of-band mechanism)
>          applies.
>
> and
>
>    The <secDNS:update> element contains an OPTIONAL "urgent" attribute.
>    In addition, the <secDNS:dsData> element contains OPTIONAL <secDNS:
>    maxSigLife> and <secDNS:keyData> elements.  The server MUST abort
>    command processing and respond with an appropriate EPP error if the
>    values provided by the client can not be accepted for syntax or
>    policy reasons.
>
>
> While those are not TTL per se they are in the same bag: they try to
> influence what the registry publishes at the DNS level.
>
> And while most registries implement this EPP extension to do DNSSEC
> operations I know of not one of them honoring the above two parameters
> (but I can certainly miss some).
>
> So I am pretty sure that even if you defined an EPP mapping to pass TTL
> data, very few registries, if not none, would use it. But that is just
> my opinion, I am not a registry nor speaking for them.
>

Thanks! My sense from working at a registry in the past and knowing folks
at others, is that you are probably right.

Shumon.