This draft is well-written and addresses a real operational concern: the breaking of delegations when processing CDS/CDNSKEY and CSYNC records from an out-of-step nameserver.


From a specification-purity point of view, the concept of multiple providers is actually not needed or relevant to this draft.  Nameservers could be out of sync for a variety of reasons.  This draft could be written without a single mention of multi-provider (multi-homed?) or multi-signer situations and be shorter and perhaps clearer.  Although, it might be important to point out that there are more reasons than just being out-of-sync from a single primary source.

On the other hand, knowing that multiple provider setups exist is a strong motivator for this specification.  Without considering multiple provider setups, we are prone to imagining that all setups are synced from a single source, and all deviation is temporal and temporary.


This draft uses the term "multi-homing" in a number of places.  I'm not aware of that being a generally understood term in the context of DNS.  The draft seems to use "multi-homing" and "multi-provider" interchangeably.  "Multi-provider" is more understandable to me from its plain meaning, but it is also not defined.  RFC 8901 uses the term "Multi Signer", and does not define any other terms for this class of operational situations.  Appendix A.3 of this draft almost defines the term as "Permanent Multi-Signer", although RFC 8901 generally refers to Multi Signer as permanent.

If the draft is not recast to just not directly mention multi-homing/multi-provider/multi-signing setups, it should define the term near the start of the draft.  I would prefer using "multi-provider" because I believe it is both clearer and less encumbered with other meanings in nearby subjects (like networking), and perhaps covers more situations than "multi-signer".


My last major concern is with section 2.2, CSYNC.  RFC 7477 has many rules that a parental agent must consider before accepting a CSYNC update.  It is unclear how those rules interact with the rules specified in section 2.2.  I think what is meant is this:

    Each parent-side nameserver is queried for the CSYNC RRset and the synced (NS, A, AAAA) RRsets, and that unless all of the CSYNC type map bits and sync data match, syncing must be aborted.

I think some discussion of how this interacts with the existing rules is warranted.  For example, the type bitmap indicates "A", but the nameservers are not at/below the delegation, so are ignored.  Does it matter to the algorithm if the child nameservers have different data for the glue records?


I have a few minor language tweaks that I noted while reading this draft.

In the abstract:

    Parent-side entities (e.g. Registries, Registrars) typically discover these records by querying them from the child, and then use them to update the delegation's DS RRset accordingly.

Since we are already talking about both CDS/CDNSKEY and CSYNC, we should probably be a little more inclusive here:

  Parent-side entities (e.g. Registries, Registrars) typically discover these records by querying them from the child, and then use them to update the delegation's DS and/or NS RRset accordingly.

Although that also doesn't quite capture everything, either.

In section 2, "Processing Requirements"

    When a response cannot be obtained from a given nameserver, the Parental Agent SHOULD attempt obtaining it at a later time

should be:

    When a response cannot be obtained from a given nameserver, the Parental Agent SHOULD attempt to obtain it at a later time


I will point that I noted some concern about the overall approach in the IETF 117 dnsops meeting.  I don't entirely recall the details of the concerns, but I think it was about making CDS/et al. more brittle operationally.  This would be true if this draft were not clear about how to handle non-responsive nameservers.