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.