On Fri, Feb 28, 2025 at 10:19 AM Peter Thomassen <[email protected]> wrote:
> Hi Paul, > > Thank you very much for your thorough review! > Thanks for the detailed response as well! As for SVCB, the WG has discussed this on various occasions and rejected > the idea. [...] Thanks for the pointers to those discussions! Scheme value 1 is not "CSTYLE sync"; rather, the scheme is about how to > contact the endpoint (here: via DNS NOTIFY; another scheme could be: via > DNS UPDATE, or via a REST call). > > But, of course it's indeed easier with a mnemonic. We've added this to the > draft. > Thanks! > > 2) Why is CDNSKEY lumped in with CDS and why re-use an RRtype as signal? > > > > I see this is explained later on in the document. It reveals that using > > a single RRtype is perhaps not the best signal at all. If we are doing > > a notify, why not contain the bits the child actually needs (eg which > > child-side RRtypes can be consumed by the parent) > > > > Why not instead of reusing a RRtype, use an NSEC-style bitmap value. This > > way, the parent can say which RRtypes it can consume and receive notifies > > for (eg CDS+CDNSKEY, or even CDS+CDNSKEY+CSYNC). This has an additional > > advantage that the child can pick their preferred method in order, eg > CDS, > > then CDNSKEY then CSYNC, because they can determine which types the > parent > > supports (without lumping CDS and CDNSKEY together). It also reduces the > > RRset to 1 entry per scheme at most, and doesn't weirdly munge CDS with > > CDNSKEY. > > > > Another consideration to ponder is about adding a "weight" like MX > > records, so parents can convey a preference for a scheme+rrtype, which > > would even allow them to signal a migration of their scanner > capabilities. > > This would require CDS/CDNSKEY to be split properly. > > The NOTIFY message was re-used because the purpose of the notification is > to tell the parent registry/registrar: "please do now whatever you would do > if your delegation scanner had expired", in full analogy to a secondary > doing an early XFR. > > It is not in scope for the sender of this notification to know about the > things that the parent would do in response, or for the parent to somehow > signal its policy. While that is also conceivable, this protocol is > designed to remove the downsides of periodic scanning with minimal overhead. > That's fair. Thanks for the explanation. > The authors fail to see what a weight field would have to do with (not) > splitting the CDS/CDNSKEY signals. A weight field would certainly be > conceivable, but did not come up during consideration by the WG (probably > because it would be far more complex). > I should have probably made it a separate item. Regardless, it is fine. I agree that svcb and weights would increase the complexity. > 3) bootstrap ? > > > > The document does not mention that using this mechanism to bootstrap is > > not allowed. Eg if the child zone was unsigned, and it adds DNSSEC, I > > don't see where this document states it CANNOT do a NOTIFY(CDS) to get > > an initial DS record published. Is this intentional? > > Yes; in fact it is allowed, as noted in the abstract and in Section 4. > Note that the notification message does not carry any sensitive > information; rather, it's a hint for the parent to do whatever if would do > later based on CDS/CDNSKEY scanning. That is, if the parent does DS > bootstrapping through *some* mechanism, then the notification allows > earlier execution. There's no reason to disallow bootstrap triggering > through NOTIFY. > I guess it wasn't as clear to me that this was really providing just a "hint for action", as can also seen by my further comments below. How about making this a little more clear in the Abstract? Feel free to take the below text as a hint to use or ignore (eg it is not a blocking DISCUSS issue anymore): CURRENT: This document extends the use of DNS NOTIFY (RFC 1996) beyond conventional zone transfer hints, bringing the benefits of ad-hoc notifications to DNS delegation maintenance in general. Use cases include DNSSEC bootstrapping and key rollovers hints, and quicker changes to a delegation's NS record set. PROPOSED: The DNS NOTIFY (RFC 1996) defines a method for the child zone to notify a secondary zone that it should initiate a zone transfer action from the primary. This document generalizes and extends this concept of the DNS NOTIFY to allow sending other type of notifications via the DNS protocol that were lacking a trigger mechanusm. This document creates a registry for new notification types and adds notifications for supporting parental NS and DS record updates, including DNSSEC bootstrapping. While notifications can be secured via access control mechanisms, this is not a requirement as the notifications merely signal to the receiver that they can or should initiate their regular (secured or not) actions as normal. Or maybe some of this text can be put in the Security Considerations ? > If so, there would > > have to be some talk in the Security Considerations on how to do this > > safely (I am not convinced this is possible, especially when allowing > > a reasonable short/instant trigger time where a temporary resource is > > maliciously acquired (eg root on nameserver or BGP route change through > > attacker) > > Triggering DS bootstrapping using a notification reuses the same security > model that the parent registry/registrar has accepted for whatever > bootstrapping procedure they're using. The notification is merely a timing > hint. The parent is free to require authentication for bootstrapping, e.g., > via RFC 9615. > Please add this text to the Security Considerations! It's a good and helpful reminder. > Or even the case when there is no DNSSEC at the child at all, can it ask > > for a CSYNC to update NS records while there is no possible > authentication > > of child records via DNSSEC? > > No, because CSYNC requires DNSSEC (see last paragraph of RFC 7477 Section > 2). Again, a notification is just a nudge for the parent to look for CSYNC > now (as opposed to later); it does not change any of the CSYNC processing > itself. > Ah great. (sorry for not deep diving into the CSYNC spec :) > Target > > [...] > > This name MUST resolve to one or more address records. > > > > Maybe more explicitly say this can be A, AAAA, CNAME or DNAME. And > > then discuss the disadvantage of indirection records? > > (this is assuming that "resolve to" is meant here to allow CNAMEs? If > not, > > then I would like to discuss that as well :) > > The authors believe that the concepts of different address families and > CNAME/DNAME indirection are included in the notion of "resolving", and that > this document is not the right place to discuss indirection. The authors > also don't think it's clearly a disadvantage for a registrar to put a CNAME > on their endpoint target (for example). > That's fair. > > > If for some reason the parent operator cannot publish wildcard > records, > > > > Why accomodate for a case that should not apply anywhere. Wildcards are > a core > > part of the DNS protocol. Can someone explain to me why this protocol > exception > > is made? > > This provision was included to address concerns that gTLD operators would, > for policy reasons, not be allowed to include wildcards in their zones. > Despite attempting to clarify, there is no consensus about the conditions > under which this is (not) the case. Authors agree that if operators end up > using wildcards, that's even better. > Thanks for the explanation. > A new revision will be submitted once other IESG feedback has been > included. Until then, you can preview changes here: > https://github.com/peterthomassen/draft-ietf-dnsop-generalized-notify/pull/39/commits I have no blocking comments left, so once I see the new draft I will change my DISCUSS to Yes. Thanks again for the detailed response! Paul
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
