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
