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, 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 :) 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 "constructing" a QNAME. _______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
