[DNSOP] Dnsdir early review of draft-ietf-dnsop-generalized-notify-01

[Patrick Mevzek via Datatracker <[e-mail]>]

Reviewer: Patrick Mevzek
Review result: Not Ready

I have been selected as the DNS Directorate reviewer for this draft. The DNS
Directorate seeks to review all DNS or DNS-related drafts as they pass through
IETF last call and IESG review, and sometimes on special request. The purpose
of the review is to provide assistance to the ADs. For more information about
the DNS Directorate, please see https://wiki.ietf.org/en/group/dnsdir

The draft does not propose changes to the DNS protocol, but extends the
semantics of NOTIFY message previously defined only for SOA, and adds a new
record called DSYNC. It does not create new behavior for entities not wanting
to use this mechanism.

Notes in chronological order, with various levels of importance.

§1.2

"One refers to the NOTIFY message, sent from a DNSSEC signer or name server"
In case of a multi-signer DNSSEC setup (model 2), there will be multiple
signers, and hence each can send a NOTIFY(CDS) message to the relevant party.
Is there a need to give more details on what should happen then?

"The second is a proposed new DNS record type, with the suggested mnemonic
"NOTIFY". " But the record later defined is "DSYNC" so I understand a previous
change happened, but needs to be applied there too.

Namewise and bikeshedding level, I find DSYNC to be far too close to CSYNC as
name. Also `_signal` is used later on, maybe something identical or close could
be used for both the record type name and specific record name?

§2.1 "Potential notification senders, knowing the name of the parent zone, can
then simply look up that information." seems a little rushed to me. From a
given sender, that starts only with the zone he is concerned with, like
`myzone.example.` what is the process to know the parent zone? (maybe
referencing the zone cut finding algorithm in appendix A of RFC7816 ?)

With this example, probably trivial. But what if `admin.myzone.example.` is
delegated out of `myzone.example.` which is itself delegated from `example.`
zone? Sender concerned with `admin.myzone.example.` zone should "climb to the
root" or not? If he doesn't find the "signal" in first parent
(`myzone.example`) should it continue further to `example.`? Probably not I
guess, but maybe worth mentioning?

A registrar can infer the parent zone immediately, as it stems from the
registration of the domain. A DNS provider with any random zone can not
immediately infer the parent just by looking at the string.

"It is strongly desirable that the notification sender is able to figure out
where to send the NOTIFY via a single lookup"
 seems to contradict later the algorithm in §4.1/3 that involves lots of steps
 in case of first negative reply.

§2.2 This section introduces the special `_signal` domain, without
explaining it too much. Is that name mandatory or is any other one ok too? Is
the format with leading underscore mandatory (and why) or not? Etc.

Considering how scheme and port are defined in §3.1, also maybe better to have
real examples with real plausible values for scheme and port instead of the
words.

"(Note that this is a generic method, allowing the parent to securely publish
other sorts of information about a child that currently is not easily
represented in DNS, such as the registrar's identity.)" I am not sure about
what this adds to the specification, and also how real it is in the sense of
how "other sorts of information" will be published, if that means with the
DSYNC record? Or because of the special record name? As for the registrar's
identity is this meant as "because its domain appear in the target"?

"the parent's designated notification target may relay notifications to the
registrar, e.g. via an EPP call, " Out of scope of document, but bringing
additional problems as the EPP channel is under control of the registrar, a
registry has no way to push data if registrar does not ask it. There are
registry notifications messages that technically could be "anything" but need
an explicit action from registrar to be retrieved, otherwise they can sit in a
queue on registry side without leaving it.

§3.1
* "RRtype The type of generalized NOTIFY that this DSYNC RR defines the desired
target address for. For now, only CDS and CSYNC are supported values."

Maybe obvious but this doesn't explain the values to use. Reference the IANA
registry for record types values? Also it might be worth here reinforcing the
point that CDS means in fact CDS or CDNSKEY treatment, even if only CDS is used
as value.

* I am not sure to understand what the scheme does.
It is defined as "The scheme for locating the desired notification address. "
yet later in §3.2 scheme=1 is defined as what to do, and not how to locate the
notification address.

scheme=0 is an error, but what purpose does it achieve?
(what does it mean precisely if parent publishes only scheme=0 records? what
should then be the port and target? is this supposed to be similar to "null
MX"/"null SRV"/"null CAA" records?)

* can there be multiple DSYNC record for same rrtype but potentially different
scheme/port/target? What would be client behavior then? Use all? Pick one
arbitrarily? Pick one through a specific ordering? Related to previous point,
what to do if one is scheme=0 and another scheme=1?

* for target, I read "This name MUST resolve to one or more address records."
It may be worth detailing:
 - are CNAME allowed there? (they aren't in NS/MX/SRV that serve as similar
 signalling setup) - what should happen if the name does not resolve? - how to
 proceed in case of multiple addresses? Should the sender send a notify to all
 of them? Any one of them? What if it gets a timeout or error, should it retry
 with another one? Etc.

* not sure myself, but should there be a note telling if target can be a DNS
compressed name or is forbidden to be?

§3.2
"Description of internal processing in the recipient end or for locating the
recipient are out of scope of this document." Not understanding the second part
of the sentence, or maybe related to  one of my previous comment. I think there
should be more details on "find the parent", as in the past everything related
to "climb to the root" semantics created problems. Specifically also when
scheme above is defined as "locating the desired notification address"

Ok I see this addressed somehow in §4.1 but I have there the following points:
- "If the negative response indicates that the parent is more than one label
away from the _signal label," might be obvious but maybe worth explaining
exactly how one can observe that (where in the negative response)

§3.2 + §3.3 : example of records do not use the `_signal` name anymore

§3.3
I agree with the rationale given and maybe there is merit keeping it in final
document, like in an appendix.

Separately, I do agree with SRV records being too constrained to be able to
extend them in any way that won't be a hack, but at the same time the new SVCB
records are far more open to extensions, so were they discussed and rejected as
well? Otherwise I believe they could do the same as DSYNC, and would avoid
having to create a new record type "just" for this notify need. Specially since
a specific record name is used, so by itself it should be enough to
discriminate what the content is about, even without a specific record type.
And hence the record name could be `_notify._tcp` or similar (see discussion in
draft-andrews-dnsop-update-parent-zones-04 referenced from RFC7344 about
finding parent) to remain aligned with other SRV/SVCB record names. Or maybe
just _dns as RFC9461? Maybe SVCB records may also help to deal better with the
case where parent publishes a target not its own but of registrar sponsoring
the name.

§4.2
"In such cases, the registrar notification endpoint should be published in the
parent zone" While not strictly in scope of the document, it is unclear to me
how this would happen. (by which means the registrar give that data to registry
and when? also it can vary per zone. what happens when a name changes registrar
- should the registry automatically remove the existing DSYNC record pointing
now to old registrar? etc.)

§5
I believe is missing a discussion for the case where the parent has as target a
registrar controlled name (instead of itself). If this is wrong/outdated, the
client get that data and will query this wrong target. In a way, the registry
is suddenly publishing information that can DOS the registrar, while leaving
the client be the source of the DOS traffic. You may say it is similar to wrong
NS records published by registry, sending traffic where it shouldn't go, as
exercised by any client.

§6
The table is unclear to me. What does the last line with 128-255 refer to?
Range is written below scheme. What about other values? Other types?
You probably need to specify that 0 is an error and 2-127 are unspecified.
As you create a registry for those values, you probably need to explain how
future ones would be assigned (RFC required? expert review? open?)

Also I think you need to ask IANA to assign a record type integer value for the
new DSYNC record type.

Generic points:
- while maybe trivial/obvious, maybe a discussion about bootstrap, if DSYNC
appears in a zone not currently/yet DNSSEC signed (tied to another point below
in nitpicks) - it would be good to have more details/advices on the "error"
path: if the notify fails (timeout, or explicit return code of failure), what
should happen? A retry? When/How? etc. Or are §3.5+3.6 of RFC1996 good enough
there? - globally, I think the case of "DNS provider -> Notify to parent" be
described correctly if parent does not involve the registrar (when it is not
the DNS provider), but if registrar has to be involved, I feel there are not
enough details in document. I am not sure, but out of scope of document, how it
even makes sense/is relevant for a registry to bother with publishing DSYNC
records and having a way to populate them with data coming from registrars when
not aiming to handle notify messages itself, as this seem lots of
work/infrastructure, where instead just dealing itself directly with notify
messages may be simpler. - should this document specifically ask to be added in
RFC1996 as updating it? - I believe ICANN enforce restrictions on what a
registry can publish in zone, besides all the delegations and related records;
has it been double checked that `_signal.$TLD DSYNC` record would indeed be
allowed to be published by registries under ICANN contracts? (this is not
strictly in scope of document, but if document creates a situation already
known to be difficult to put in place, not for technical but contractual
reasons, it may be a motivation to find other ways or provide alternatives)

Nitpicks:
- §2.2 and elsewhere, please use domain names out of RFC2606 only
- §4.1 "and validate the response if DNSSEC is enabled." which seems to say
that DNSSEC is not mandatory. Ok, maybe for NOTIFY(CSYNC) it could be allowed
to have the parent NOT DNSSEC signed, but for a NOTIFY(CDS) and hence DSYNC CDS
record, I think it makes sense only if the parent is signed, so has to validate
- also §4.1 maybe add more details on what to do if getting other errors than
NXDOMAIN? Should algorithm stop there, or be continued? Like if
`foobar._signal.example` query fails, should client still try `_signal.example`
next or just abandon process? - §4.2 "it is expected that in the ICANN RRR
model" Not sure ICANN is needed there, and maybe reference something explaining
RRR which is nowhere expanded (appears in §2.2 too, but not explained there
either) Term is not defined in RFC on DNS terminology and I think I have seen a
draft for like "domain terminology related to registrations" but not finding it
now, sorry. - §8 "DNSSEC automation" should maybe refer more to
draft-ietf-dnsop-dnssec-automation now Not being an IETF process expert, so I
can be wrong, but won't this draft be blocked until the DNSSEC automation I-D
is published as RFC itself, since it is mentioned as Normative here and not
Informative? - structure of document seems a little hard to read because 3
subjects (having to send notifies, having to find out where to send them, and
having to publish data to tell where to send them) are like split and spread
throughout the document. DSYNC record for example is presented even before
being defined fully. I have no specific suggestion, but maybe another order
could improve reading.