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.
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.
#### 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/.
#### 5.1 Recommendations
389 1. For certain DS updates (see analysis (Section 5.2)) and for DS
390 deactivation, relevant points of contact known to the parent-side
391 entity (registry or registrar) SHOULD be notified.
393 2. For error conditions, the child DNS operator and the domain's
394 technical contact (if applicable) SHOULD be notified first. The
395 registrant SHOULD NOT be notified unless the problem persists for
396 a prolonged amount of time (e.g., three days).
398 3. Child DNS operators SHOULD be notified of errors using a report
399 query [RFC9567] to the agent domain as described in Section 4 of
400 [RFC9859]. Notifications to humans (domain holder) will be
401 performed in accordance with the communication preferences
402 established with the parent-side entity. The same condition
403 SHOULD NOT be reported unnecessarily frequently to the same
404 recipient.
406 4. In the RRR model, registries performing DS automation SHOULD
407 inform the registrar of any DS record changes via the EPP Change
408 Poll Extension [RFC8590] or a similar channel.
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.
These seem to be a mixture of policy recommendations and good technical
practices. If reporting is not required for interoperation, these should
probably all be lower case "should".
If reporting is required for proper DS automation, then at least some of this
is a MUST.
Reporting is not required for automation; other means of detecting errors are
possible (such as when the child operator monitors update success).
Indeed,
https://datatracker.ietf.org/doc/statement-iesg-statement-on-clarifying-the-use-of-bcp-14-key-words/
says that normative statements not immediately needed for interoperability
should not use uppercase key words. I made a note for the next revision to
lowercase the key words in recommendations 1, 2, 5. As recommendations 3 and 4
pertain to using a certain protocol, I believe uppercase remains appropriate
there.
#### 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?
#### 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.
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.
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§ion=7
----------------------------------------------------------------------
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.
Best,
Peter
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
