[DNSOP] Re: Andy Newton's Discuss on draft-ietf-dnsop-ds-automation-08: (with DISCUSS and COMMENT)

[Andy Newton <[e-mail]>]

Peter,

Thanks for the response.

On 20-05-2026 7:14 AM, Peter Thomassen wrote:
> Hi Andy,
> 
> Thank you very much for your review!
> 
> On 5/20/26 00:34, Andy Newton via Datatracker wrote:
>> ----------------------------------------------------------------------
>> DISCUSS:
>> ----------------------------------------------------------------------
> [...]
>> #### 5-15 Minutes
>>
>> 240        2.  Parent-side entities (such as registries) SHOULD reduce a DS
>> 241            record set's TTL to a value between 5–15 minutes when a new set
>> 242            of records is published, and restore the normal TTL value at a
>> 243            later occasion (but not before the previous DS RRset's TTL has
>> 244            expired).
>>
>> Why isn't this a MUST? It is a SHOULD for both behaviors (the 5-15 minute TTL)
>> and the restoration of the TTL. At the very least, it seems the restoration of
>> the "normal" TTL value is a MUST. However, why isn't the 5-15 minute value a
>> MUST? Otherwise an operator can set it to 5 years justified with "because I
>> just wanted it that way". If the SHOULD is to remain, isn't there a reasonable
>> upper boundary behavior such as not being greater than the normal TTL value?
> 
> Two thoughts:
> 
> - TTLs accepted by resolvers are bounded in practice. Most do not accept arbitrarily long TTLs, as that has other security issues such as retaining a hijacked delegation beyond its actual removal. I can collect numbers if needed, but my recollection is that TTLs over 1-2d are not honored in practice.
> 
> - The above resolver-side constraint aside, parents can set whatever TTLs they want, even without DS automation. DS automation does not change that. The point of this provision in the document is to mitigate the impact of a botched DS update, not to give general recommendations about what TTLs should be used in a TLD registry. (In practice, TTLs in TLD zones vary between 1h and 48h.)
> 
> - It's not a MUST because there is no problem if the registry uses a TTL of 20 or 30 minutes permanently, for example. Also, when DS automation is performed by the registrar, the registrar may not have the ability to enforce TTL adjustment. -- Now one could say that the document should take the stance that DS automation is to be done by registries and not registrars. However, getting into that discussion was very very clearly rejected by many participants: the registries and registrars want to sort out these responsibilities between themselves. And indeed, it's a business decision, not primarily a technical one.

If there are no interoperability issues with the registry setting 30 minutes as the TTL value, which is outside the 5 to 15 minute suggestion, then this is not a normative requirement and the SHOULD is to be lower-cased and/or changed to use non-BCP14 language.

> 
>> Also, is "normal TTL value" the previous TTL value? If not, what does that mean?
> 
> The "normal TTL value" is indeed the "previous" one when an update is applied. However, for DS initialization, there is no previous one, so the term would only capture updates.
> 
> Happy to change to a better adjective if it's not clear (pls let me know if you have another suggestion). OTOH, this was widely reviewed in the DNS and registry space (e.g., CENTR, APTLD, DNS OARC) and it seems like the use of "normal" was generally clear to the intended audience.

Some could have interpreted it as the previous value and others the default value by policy. I think it is best to be explicit. Perhaps "previous TTL value or default TTL value absent a previous value".

> 
>> #### Both CDNSKEY and CDS
>>
>> 246        3.  DNS operators SHOULD publish both CDNSKEY and CDS records, and
>> 247            follow best practice for the choice of hash digest type
>> 248            [DS-IANA].
>>
>> Section 4.2.3 does a good job of explaining why both CDNSKEY and CDS are
>> needed, so it seems the justification here is a MUST. In other words, if you
>> want to interoperate, the operator MUST do this otherwise there is likely to be
>> a problem.
> 
> There is no problem if the child operator knows which type of update format (CDS or CDNSKEY) the parent consumes. There would only be a problem if the parent insisted on both being published. Indeed, that provision was part of the draft, but was removed in -01 due to argument that it's not a good idea to reject an update just because a redundant format is missing.
> 
> A written record of this argument can be found at https://mailarchive.ietf.org/arch/msg/dnsop/ObpPwt5_HrmsPXE3dG8CrJUP9mg/; more feedback in that direction was gathered during an in-person workshop at DNS OARC 45.
> 
> Given these points, it seems not generally required for interoperability to publish both CDS and CDNSKEY, although if you do so you can be agnostic about the parent's preference and avoid certain risks. But, if you know what you're doing and what the parent expects, the risk goes away. Hence the SHOULD.
> 
> See also https://mailarchive.ietf.org/arch/msg/dnsop/Uv-oyqj-gp1dlfPIofct22Ijqo0/.

Why can't the guidance be more explicit? "Unless the child and parent have agreed upon using either CDS or CDNSKEY, DNS operators MUST publish both CDNSKEY and CDS."

>> #### DS update requests
>>
>> 659        2.  DS update requests SHOULD be executed immediately after
>> 660            verification of their authenticity, regardless of whether they
>> 661            are received in-band or via an out-of-band channel.
>>
>> For proper DS automation, shouldn't this be a MUST? If not immediately, then as
>> soon as possible. Or is it ok for an operator to wait 24 hours?
> 
> The publication intervals for delegation-centric zones (especially TLDs) vary greatly; some publish near-realtime, some publish zonefiles once a day. "MUST immediately" does not match the operational reality of a significant fraction of deployments.
> 
> However, we could say "MUST be executed at the next publication opportunity", or similar. Would that address your concern?

Yes, that works.

> 
>> #### SHOULD NOT initialize
>>
>> 675        5.  In the RRR model, a registry SHOULD NOT automatically initialize
>> 676            DS records when it is known that the registrar does not provide a
>> 677            way for the domain holder to later disable DNSSEC.  If the
>> 678            registrar has declared that it performs automated DS maintenance,
>> 679            the registry SHOULD publish the registrar's [RFC9859]
>> 680            notification endpoint (if applicable) and refrain from registry-
>> 681            side DS automation.
>>
>> Under what conditions are violating these SHOULD NOT/SHOULD acceptable?
>> If there are conditions for doing so, the document should attempt to describe
>> those conditions. Otherwise, aren't these MUST NOT and MUST?
> 
> It's a little complicated. First, about the SHOULD NOT:
> 
> At OARC 45, it was proposed to even remove this provision, because a registrant can always change registrars when they don't like that their registrar doesn't provide a way to remove a DS record when needed. That's of course not very helpful when you're already locked up in a situation where a DS record has been provisioned, and now you can't get rid of it. I'm pointing this out to illustrate that this recommendation itself (independently of which normative word is used) has only rough consensus.
> 
> At OARC 45, it was also discussed to tighten this recommendation. This was deemed unrealistic by registries as there is no protocol for a registry to discover whether a registrar provides a channel for removing a DS record. It seems impossible to design such a protocol that would be more likely to be adopted by registrars than the DS-removal channel itself. Registries present in the room therefore clearly stated that they don't want to be responsible for missing knowledge about which registrar is defective in that sense, and a tighter version did not find consensus.

There may not be a protocol, but there is a relationship between registries and registrars. They exchange money, credentials, allow lists, etc... so there is an opportunity for a registry to learn this about the registrar.

> 
> OTOH, in the gTLD space, registrars are contractually obliged to provide a DS provisioning channel (which I think includes removal), so this recommendation really applies in the ccTLD space only. The scope of this recommendation (and the consequences of it being suboptimal in a way) therefore is not as broad as it might seem at first sight. The SHOULD is supposed to be a strong technical hint ("undesirable stuff happening if you don't adhere!") that takes the above consensus complications into account.

IMHO, this is a MUST NOT as DS automation interoperation can be harmed (assuming removing DS records is a requirement for DS automation). The only reason I can think that the guidance is SHOULD NOT would be if the registry has some fore knowledge that the registrant would never disable DNSSEC.... and that seems implausible.

> 
> As for the SHOULD, no problems are expected if the registry does not publish the RFC9859 notification endpoint. In that case, the registrar may do CDS/CDNSKEY scanning [1][2] and all is fine. Notifications only offer a timing advantage. There is also no problem if the registry does not stop DS automation while the registrar does so as well, as DS updates are idempotent. Parallel automation therefore is unnecessary and wasteful, but not strictly an interoperability problem. For details, see Section 7.2.3 of the draft.
> 
> Examples of registrars doing CDS/CDNSKEY scanning:
> [1] hourly: https://docs.glauca.digital/domains/cds/
> [2] daily: https://domainname.shop/faq?id=395&section=7

Given your explanation, the SHOULD does not seem to be normative.

> 
>> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
>>
>> ## Comments
>>
>> ### EPP Advertising
>>
>> 309        ...  When using the Extensible
>> 310        Provisioning Protocol (EPP) [RFC5730], the domain <info> command
>> 311        described in Section 2.1.1.2 of [RFC9803] is available for
>> 312        advertising the server's TTL policy.
>>
>> The use of the word "advertising" makes me read this as information being
>> provided to the public. However, EPP does not operate that way. I think should
>> be reworded to say EPP can be used to make known to the registrar the
>> acceptable values used by the registry.
> 
> Will do.
> 
>> ### RDAP TTLs
>>
>> 410        5.  The currently active DS configuration SHOULD be made accessible
>> 411            to the registrant (or their designated party) through the
>> 412            customer portal available for domain management.  The DS update
>> 413            history MAY be made available in the same way.
>>
>> https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-ttl-extension/ is also
>> a good way to make the currently active TTL values available to the registrant
>> or their designated party.
> 
> I will make a note in Section 5.2. My impression is that publicly stating the TTL policy would belong into DNSSEC Practice Statements, so I'd be reluctant to include it as a recommendation.

I agree. That is only informative, as is all of item 5.

-andy, ART AD