[DNSOP] Paul Wouters' Discuss on draft-ietf-dnsop-generalized-notify-06: (with DISCUSS and COMMENT)
Paul Wouters has entered the following ballot position for draft-ietf-dnsop-generalized-notify-06: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-generalized-notify/ -- DISCUSS: -- I have a few questions and suggestions I'd like to DISCUSS. Part of these might be answered by the emails on the dnsop list, but I have not been able to follow all email there. 1) Why not use an SVCB RRtype ? It would have more flexibility, avoid the SCHEME registry, properly decouple CDS and CDNSKEY, and would not require a new RRTYPE. 2) Why use a numbered Scheme? These are not very friendly to DNS admins. I'm a semi-advanced DNS person and still have to look up the numbers around NSEC, RRSIG, etc. If I look at the Scheme table introduced: CDS 1 Delegation management (this document) CSYNC 1 Delegation management (this document) Scheme value 1 seems to be "CSTYLE" sync ? Why not give it such a name for the presentation format? Let's not make the same mistake as with TLSA Usage that had to issue RFC7218 to introduce names for numbers because people just never got the numbers right. 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. 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? 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) 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? It would be good to make this more clear in the protocol specification. -- COMMENT: -- Note with my old-man-hat on, I am kinda amused it took like 15 years for the huge "triggers vs timers" discussion to come up with a solution for both timers and triggers after all :P All other values are currently unspecified. Did you mean unassigned instead of unspecified ? Port The port on the target host of the notification service. This is a 16-bit unsigned integer in network byte order. Maybe say "if 0, ignore this DSYNC RR" ? Target [...] This name MUST resolve to one or more address records. Maybe more explicitly say this can be A, , 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 :) 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? Construct the lookup name, by injecting "injecting" seems a weird term here. We are "construct
[DNSOP] Re: New Version Notification for draft-nottingham-public-resolver-errors-01.txt
Hi Vittorio, > On 26 Feb 2025, at 12:43 am, Vittorio Bertola > wrote: > >> >> Il 22/02/2025 01:40 WET Mark Nottingham ha >> scritto: >> Hi DNS folk, >> See draft below for an update based upon feedback received. Note that the >> short name of the draft isn't really accurate any more, since some of the >> feedback was that this could/should be potentially applicable to other >> resolvers too. > Was there any consideration of the potential workload that this model would > put on IANA? If each resolver of the planet (or even just each resolver run > by an entity that provides Internet connectivity services to end-users) had > to register and get a resolver ID, the registry could become quite sizeable - > but perhaps this would not be an issue. The intent is not to scale to that degree -- indeed, that would be considered a failure, because it would indicate widespread censorship on the Internet. Instead, it's to selectively surface legally mandated censorship when it impacts 'large' services (such as public resolvers) to raise user awareness and reduce confusion. > In general, I am not too convinced by this proposal. Authenticating these > error messages a little better through the registry + URI (domain name) > control mechanism could be a positive thing, but only if it does not > contribute to the gatekeeping of user communication by the browsers. In fact, > at the end of section 1 the draft states clearly that the mechanism will > allow web browsers to decide which resolver operators (ISPs etc) will be > allowed to show explanatory messages to end-users when enacting filters, and > this is yet another centralization of control into the browser oligopoly. I > see the potential risk in enabling any resolver to show arbitrary messages to > users, but possibly the browsers should focus on controlling what kind of > message is presented to the users, rather than who is sending it. If you have a means of doing so without increasing the risk of arbitrary censorship that *isn't* legally mandated, I'm very receptive. From my standpoint, it's necessary to have some party making a judgement call about who is using this mechanism responsibly, and while I share your discomfort with concentration of power, browser vendors are well placed for this, experienced in making such calls, already in place, and seemingly distant from any significant conflict of interest (at least as far as I can see). Cheers, -- Mark Nottingham https://www.mnot.net/ ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP] Re: Fwd: New Version Notification for draft-nottingham-public-resolver-errors-01.txt
> Il 22/02/2025 01:40 WET Mark Nottingham ha > scritto: > > > Hi DNS folk, > > See draft below for an update based upon feedback received. Note that the > short name of the draft isn't really accurate any more, since some of the > feedback was that this could/should be potentially applicable to other > resolvers too. > Was there any consideration of the potential workload that this model would put on IANA? If each resolver of the planet (or even just each resolver run by an entity that provides Internet connectivity services to end-users) had to register and get a resolver ID, the registry could become quite sizeable - but perhaps this would not be an issue. In general, I am not too convinced by this proposal. Authenticating these error messages a little better through the registry + URI (domain name) control mechanism could be a positive thing, but only if it does not contribute to the gatekeeping of user communication by the browsers. In fact, at the end of section 1 the draft states clearly that the mechanism will allow web browsers to decide which resolver operators (ISPs etc) will be allowed to show explanatory messages to end-users when enacting filters, and this is yet another centralization of control into the browser oligopoly. I see the potential risk in enabling any resolver to show arbitrary messages to users, but possibly the browsers should focus on controlling what kind of message is presented to the users, rather than who is sending it. Also, if in the end the deciding element for the trust is the domain name in the URI, then the registry does not add much to it, unless IANA is expected to do some trustability checks on applicants before adding their entry. -- Vittorio Bertola | Head of Policy & Innovation, Open-Xchange vittorio.bert...@open-xchange.com mailto:vittorio.bert...@open-xchange.com Office @ Via Treviso 12, 10144 Torino, Italy ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
