Hi Patrick, First of all, thank you very much for this very comprehensive review. It's been very valuable, and we have incorporate a lot of your feedback into the new revision -02 that was just uploaded.
Below some more responses. On 3/14/24 08:32, Patrick Mevzek via Datatracker wrote:
§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?
No. Also, this text is gone now since the double-use of the term NOTIFY was resolved due to the next comment.
"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.
Good catch, fixed (should have been DSYNC).
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?
We've changed the _signal label to _dsync, which is aligns with the rrtype DSYNC. Let's see if others in the WG feel that the similarity to CSYNC is an issue (the authors don't think it is one).
§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 ?)
No zone cut finding is needed; the parent zone can be found directly from the SOA record in the negative response. For clarity, this text (which also has other editorial changes) now has a reference to the corresponding section that explains that. (In other contexts where SOA records might not be returned, zone cuts need to be found some other way. But the authors don't think that applies here.)
"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.
Thank you, clarified.
§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.
It's just a name everyone has to agree to. It should be free from collisions with registered names, so an underscore in it makes sense; apart from that, it can be whatever. (Changed to _dsync, see above.)
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.
Done.
"(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"?
As this parenthetical comment didn't add anything to the spec, we've removed it.
"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.
Removed mention of EPP.
§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.
Done.
* 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.
Clarified.
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?)
It's meant for testing, and ignored by consumers. Clarified.
* 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?
We added a constrained that one "MUST NOT publish more than one DSYNC record for each combination of rrtype and scheme".
* 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.
We thought about this and think that if nothing is said explicitly, this is like any other name resolving to something (e.g. a HTTP server). CNAMEs are fine, and if multiple addresses are returned, you pick one.
* not sure myself, but should there be a note telling if target can be a DNS compressed name or is forbidden to be?
From the requirement that resolvers be agnostic of new record types, it follows that we should not allow compression. Clarified.
§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"
Indeed this is confusing; we've removed the problematic part. (I'm not sure what it was supposed to mean anyway.)
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)
Clarified that this can been taken from the SOA record that's returned with the negative response.
§3.2 + §3.3 : example of records do not use the `_signal` name anymore
Fixed (with _dsync).
§3.3 I agree with the rationale given and maybe there is merit keeping it in final document, like in an appendix.
As we think that the spec should be succinct and not keep its history, we didn't move this or remove the RFC editor note for now.
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.
Those are good points. OTOH, when using SVCB AliasMode to point at the registrar, chasing requires more complexity than in case of CNAME, which is not good. We think this could benefit from some discussion, so we'd like to put it in front of the WG.
§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.)
How the parent-side entities arrange themselves is out of scope for this document; it is assumed that they have set up things such that at any given time, the correct party listens on the published notification endpoint.
§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.
How this is arranged is out of scope (see above). Participation is optional, so if parent-side parties are free to not arrange anything..
§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?)
Section 3.1 says those are private use, and Section 6 says that expert review is required. We've expanded the table to say something about all values.
Also I think you need to ask IANA to assign a record type integer value for the new DSYNC record type.
Oops, fixed!
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)
Bootstrapping DNSSEC is specified in draft-ietf-dnsop-dnssec-bootstrapping which is currently in the RFC editor queue. What kind of discussion would you like to see here?
- 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?
We've added this in Sections 4.2.1 and 4.3.
- 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.
That may very well be the case, but it is conceivable that some registrars want to be in charge. The protocol is designed such that either way is possible.
- should this document specifically ask to be added in RFC1996 as updating it?
Why?
- 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)
Opinions on putting DSYNC records in a TLD zone differ, but one can always just delegate the _dsync label to a subzone, and put the records there.
Nitpicks: - §2.2 and elsewhere, please use domain names out of RFC2606 only
Done for the most part. (We kept a contrived real-life example in Section 4.1.)
- §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
CSYNC specifically requires DNSSEC (see RFC 7477). Apart from that, DNSSEC is recommended as usual, but schemes that are otherwise authenticated (e.g., via SIG(0)) are not excluded.
- 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?
Following the algorithm in the "Endpoint Discovery" section closely, the only paths are "return DSYNC record if retrieved" or "do this thing if response was negative". Otherwise, the algorithm just ends (= give up). We could say this explicitly by adding a fourth step: 4. Otherwise, abort. ... or something. But it almost seems like a no-op instruction (it's a step that does nothing).
- §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.
Removed mention of RRR.
- §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?
Thanks, you're correct on both accounts. Fixed!
- 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.
Agreed. We changed the order such that we now have Design Requirements (in Section 1), then the DSYNC RR Type (2), DSYNC publication (3), and delegation maintenance based on that (4). We also shuffled some other stuff, and hope all of it is clearer now. Your feedback helped make this document take a big step. Thank you! Best, Peter + co-authors -- https://desec.io/ _______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
