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

[Peter Thomassen <[e-mail]>]

Hi Andy,

Thanks for looking into my responses in detail.

Based on your suggestions, I've elevated one "SHOULD NOT" to "MUST NOT" (see below).

In total, there are now 8 MUST-level requirements in the new document.

The changes from this review are summarized in https://github.com/desec-io/draft-ietf-dnsop-ds-automation/commit/fe21c692f0e8c72840cf0514099a0bbcac869b67.

The rendered diff is currently visible at https://author-tools.ietf.org/iddiff?url1=draft-ietf-dnsop-ds-automation-08&url2=https://desec-io.github.io/draft-ietf-dnsop-ds-automation/draft-ietf-dnsop-ds-automation.txt.

On 5/20/26 15:38, Andy Newton wrote:
>>> #### 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.

Taking the DISCUSS seriously, please excuse me for mounting a discussion ;-) I will lay out my understanding but eventually defer as I don't have the necessary context on which documents may (not) make which particular use of these key words across IETF areas. Other ADs may know better than I do, so I'd prefer to eventually defer. I appreciate the learning opportunity for when I'll be serving as an editor in the future!

First, RFC 2119 Section 6 (and the IESG statement [1]) mandates to only use uppercase key words when "actually required for interoperation or to limit behavior which has potential for causing harm". The RFC itself details:

    ... potential for causing harm (e.g., limiting retransmisssions)  For
    example, they must not be used to try to impose a particular method
    on implementors where the method is not required for
    interoperability.

In this context, it seems to me that your view (~"30 minutes TTL don't cause an interoperability issue, so uppercase is inappropriate") is not compelling. For example, a higher TTL does have a slight risk of causing retransmissions, namely when the new DS record set is botched and causes SERVFAILs on lookups, which are not cacheable and will cause look-up retries. When the DS TTL is set to 5-15 minutes instead of 30, there will be less retries, as a correction to the DS RRset will be visible more quickly. The DNSOP WG has determined that 5-15 is the best, albeit not the only choice to address this risk. Yet, there is no interoperability issue when deviating a bit.

The IESG statement [1] also has a section on "Common Additional Uses of Key Words" which endorses use of uppercase key words for operational requirements, and the 5-15' recommendation arguably is an operational (soft) requirement and not just an opinion (that is, "it's best done this way").

To reiterate, this is my understanding, but I may not have the full picture across IETF areas.

[1]: https://datatracker.ietf.org/doc/statement-iesg-statement-on-clarifying-the-use-of-bcp-14-key-words/


Our discussion made me reconsider an earlier change I had confirmed in https://mailarchive.ietf.org/arch/msg/dnsop/bO0CX4FPyS907p0HZLF5Xilxbdo/, namely that the reporting recommendations in Section 5.1 should be lowercased.

That was based on the insight that, as you pointed out, reporting is not an interoperability requirement. However, the "Common Additional Uses of Key Words" section of [1] explicitly lists:

	- Operational requirements, especially around mandatory logging
	  and configuration needed to produce successful deployments

It seems to me that reporting is pretty much the same as logging, except to a different party (namely, the child operator, the registrant and the like). The guidance in the IESG's statement is not limited to actual logging, it only names it especially, yet as an example. Section 5.1 thus appears appropriately covered by this clause. As a result, I've reverted this change.

As above, I'm not objecting to making any changes if I'm in the rough; I just don't know whether I am.

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

Sounds great. I've noted down the following change for the next revision:

OLD
    restore the normal TTL value

NEW
    restore the previous (or, if unavailable, default) TTL 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."

Such agreement is not to be expected in practice, as domain registries generally do not have any sort of agreement with DNS child operators. There may be rare exceptions (which "SHOULD" would accommodate), but the registry's preferred ingestion format is normally published in their DNSSEC Practice Statement.

Additionally, such agreements are something to actually advise against, because they ossify expectations and prevent the registry to change their preferred format later. If either CDS or CDNSKEY are eventually deprecated (and removing this dichotomy would be a good thing), at least some registries would have to make that change, and agreements like the above would stand in the way. (That's why my point earlier was on the child operator "knowing" the preference, such as from a DNSSEC Practice Statement, not the registry committing to it in an agreement.)

Aren't the risks a child operator might be incurring covered by the sentence you proposed in https://mailarchive.ietf.org/arch/msg/dnsop/8hgHnyVsxVYSyGcn6oBUJT9GGzo/? I've already added this for the next revision:

    When implementing these recommendations, operators MUST mitigate
    issues arising from any particular deviation.

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

I agree with this, and I wish that such alignment could be reliably achieved. However, doesn't it seem unlikely that a registrar who's unreliable enough to not provide a DS removal mechanism would make the effort to tell all of their contracted registries about that?

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

That's correct.

I now realize that the recommendation in question says that a registry ought not to automatically initialize DS records "when it is known" that the registrar doesn't provide a way back.

Given that this is hedged with "when it is known", I now think that "MUST NOT" is indeed appropriate: Registries who don't know about that obviously can't do much (until they are told about the registrar's lacking DS-removal mechanism), but once they know, there indeed seems to be little excuse for them to not care.

So, I'll stop talking about the "how to know" complications, and have turned the "SHOULD NOT" into a "MUST NOT".

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

I think this falls under the "limiting retransmissions" provision of RFC 2119 Section 6, but again defer to others -- if the IESG think this should not be uppercase, I'll of course apply the change.

>>> ----------------------------------------------------------------------
>>> COMMENT:
>>> ----------------------------------------------------------------------
[...]
>>> ### 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.
I beg to disagree: As mentioned above, uppercase key words are fine "to limit behavior which has potential for causing harm". Operational harm is certainly imaginable when a registrant can't inspect their current configuration after it has been changed through DS automation, and the registrant wrongly assumes a different state while operating their nameserver (I'll be happy to come up with some specific instances where that could play a role).

Similarly, inspection of the DS history may help prevent operational harm by detecting when the registrar was hijacked and the adversary adjusted the DS RRset and then changed them back. (Several instances of that are known, will be happy to provide references.) Thus, I think BCP14 key words are actually appropriate for item 5.

As usual, I'll be happy to be in the rough if the IESG has a different view, and will be applying all changes you guys find consensus for.

Thanks again for arguing with me,
Peter