Hi Peter,
Thank you very much for this thorough review!
On 3/3/25 18:21, Peter van Dijk via Datatracker wrote:
While the draft is called "generalized", 1.1 immediately dives into the
parent/child synchronisation angle. I don't want to tell you to rework the
document at this stage, but it seems quite specific when introduced like this.
It's still generalized (from the SOA case). ;-) But I understand what you mean.
I've added a sentence in Section 1 to clarify the scope and motivate the remainder of the document:
NEW
Although this document primarily deals with applying generalized
notifications to the delegation maintenance use case, future
extension for other applications (such as multi-signer key exchange)
is possible.
... and renamed Section 1.1 from "Design Requirements" to "Design Requirements for Delegation Maintenance".
It seems desirable to minimize the number of steps that the
notification sender needs to figure out where to send the NOTIFY.
This sentence needs work. "needs to /perform to/ figure out" perhaps?
Done ("needs to perform in order to figure out").
(Not really sure, why, though -- it's valid to say, e.g., "how many beers to you need to get tipsy", without adding "to drink" ...)
2.3: I don't -think- you mean to say that NOTIFY(CDS) covers both CDS and
CDNSKEY, but I am not certain. That bit of text could be clearer. (It turns out
section 4 does clarify this.)
This could indeed be less confusing already in 2.3. Made the following change:
OLD
indicates that when a new CDS/CDNSKEY (or CSYNC) RRset is published,
a NOTIFY(CDS) (or NOTIFY(CSYNC)) message should be sent to the
address and port listed in the corresponding DSYNC record, using
NEW
indicates that when a new CDS/CDNSKEY (or CSYNC) RRset is published,
a NOTIFY message (see Section 4) should be sent to the address and
port listed in the corresponding DSYNC record, using [...]
under the _dsync subdomain of the parent zone, as described in the following
subsection
I suspect "following subsection" was once true, but in -07, it's the next two
subsections. Perhaps "in the rest of this section" or just "in this section" is
clearer.
Done ("in the following subsections").
The scope for the publication mechanism is therefore wider than only
to support generalized notifications, and a unified approach that
works independently of the notification method is specified in this
section.
This sentence derails itself around ", and a". Which thing is a unified
approach? The publication mechanism? The scope of it?
None; it's two independent main clauses connected with ", and". ("The sky is blue, and the weather forecast is sad.")
But apparently it's confusing, so I've changed it to:
NEW
As the scope for the publication mechanism is wider than only to
support generalized notifications, a unified approach that works
independently of the notification method is specified in this
section.
It is RECOMMENDED to secure the corresponding zone with DNSSEC.
Which zone is "the corresponding zone"? The one with the `_dsync` subdomain?
(I'm pretty sure it is, but this could be written more clearly.)
Not necessarily; it can be imagined that child._dsync is in a separate zone.
NEW
[...] It is RECOMMENDED to secure zones containing
DSYNC records with DNSSEC.
If a positive DSYNC answer results,
This appears to be legit English, but it is phrased uncommonly, causing
spurious reboots in human readers :-)
I'm not sure what causes the mental reboot :) Do you have a suggestion for improvement?
4.1 3, "parent zone labels" perhaps "parent zone label(s)" ?
It's always at least two (because of the root label; of course unless the root zone decides to use this).
4.2.1: i like the report-channel idea! Note that 9567 6.1 says "MUST NOT be
included in queries". Perhaps explicitly write down that you are making an
exception to that rule.
Good point. It seems like it's unclear whether "MUST NOT be included in queries" applies to opcode 0 (Query) or to QR=0, independently of the opcode. As it is in RFC9567's section on "reporting resolvers", I'm inclined to think that NOTIFY messages are not intended to be covered.
I have tentatively added:
NEW
[...] (The prohibition of this option in queries ([RFC9567],
Section 6.1) only applies to resolver queries and thus does not cover
NOTIFY message.)
... but I'm not sure if this is the best way to put it. Definitely open for other suggestions!
(And perhaps, 4.3 step 1 should be doing more than
flipping the QR bit - it should also remove the report-channel option. This
seems obvious so I wonder if we need to be explicit here.)
NEW
1. Acknowledge receipt by sending a NOTIFY response as described in
[RFC1996] Section 4.7 (identical to NOTIFY query, but with QR bit
set and any EDNS0 Report-Channel options removed) [...]
4.3 option 1, "period scanning" -> periodic?
Right, thanks.
4.3 option 2, I wonder if REFUSED+Blocked as a -reply- makes sense, but that
may conflict with the requirement "To prevent retries".
Agree; it seems better to stick to the retry prevention mechanisms of the NOTIFY protocol.
The last sentence of 4.3 says "oh by the way this section is for CSYNC too". I
suggest rewriting the first few sentences to de-specialise the text from CDS to
both.
Done. The beginning of 4.3 now says
NEW
The following algorithm applies to NOTIFY(CDS) and NOTIFY(CSYNC)
processing.
... and the rest of it treats them equally.
5: An unfinished thought: what if an attacker gets control over CDS/CDNSKEY in
a zone, briefly (until detection, perhaps)? Having a NOTIFY mechanism would
allow them to benefit from that small window, while scheduled checks would
require a much larger attack window.
Information that leads to (de-)publication of a DS record is supposed to be authenticated by the parent, one way or another, e.g., by the old key (RFC 7344), via authenticated bootstrapping (RFC 9615), or out of band (e.g., with a confirmation email).
The authors think that the authentication problem is orthogonal to the problem of notification. Allowing for timing gaps is not security anyway. :-)
A.1: s/replacing/augmenting/ ?
The long-term goal is actually to replace the scanners.
As we're during the cut-off period for draft submission, I've put the above changes here: https://github.com/peterthomassen/draft-ietf-dnsop-generalized-notify/pull/40/commits Happy to iterate before merging.
Best,
Peter + co-authors
--
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx
