On Tue, Feb 7, 2023 at 2:02 AM Willem Toorop <[email protected]> wrote:
> Op 28-12-2022 om 23:29 schreef Murray Kucherawy via Datatracker: > > (1) It's expected (required?), with no actions for IANA, to expressly > include a > > section that says so. It's conspicuously missing here. > > We've added the section. > Yay! > > (2) Why is there no registry for custom properties? I can see that > Section 4.5 > > takes a run at dealing with the collision risk by SHOULDing a particular > way of > > naming custom properties, but it feels to me like a registry is the > right way > > to deal with this. As a consumer of this work, I might not want to > reveal (via > > names) which DNS implementation I'm using, for example. > > We (the co-authors) discussed this and do recognize that a registry for > *properties* is a good idea and have added that to the draft (with PR > https://github.com/NLnetLabs/draft-toorop-dnsop-dns-catalog-zones/pull/67 > ) > Nice. The only thing I would say this needs now (per RFC 8126) is some guidance for the Designated Expert around what to consider a valid registration versus when to ask for changes. This isn't mandatory to provide, but it really is a good idea to put some advice here for future DEs. Since this isn't a strict requirement of RFC 8126, I'm going to clear my DISCUSS, but I suggest you consider adding some guidance text here. You and Warren can decide when it's ready to move forward. > > (3) I have a similar question about groups in Section 4.4.2; "nodnssec" > is an > > example of something that we might want to register with global > semantics, or > > more generally, that some values might be common in implementations and > > therefore worth documenting. > > Those group values are not for implementations, but for operators to > choose. We have done several modifications to clarify that: > - The group values now have non-descriptive names as to not suggest > that they have meanings in implementations (it's the operator that > determines the "meaning" and not the implementation) > - We have extended the lines about catalog producers publishing at > two consumer operators and how mapping of group values is a matter of > those producer/consumer relationships, so it now reads: > > "Implementations MAY facilitate mapping of a specific group > value to specific configuration configurable on a per catalog zone basis > to allow for producers that publish their catalog zone at multiple > consumer operators. Consumer operators SHOULD namespace their group > values to reduce the risk of having to resolve clashes." > OK. > > (4) Do we need a registry of names that are special in the context of > catalog > > zones, e.g., "zones", "ext", "group", "version", "coo", "invalid"? > > We have added a registry for catalog zones properties, already > provisioned with "zones", "ext", "group", "version" and "coo". > The latest version of the IANA registry (including "zones") can be seen > here: > > > https://github.com/NLnetLabs/draft-toorop-dnsop-dns-catalog-zones/blob/master/draft-ietf-dnsop-dns-catalog-zones.md#iana-considerations-iana > > "invalid" is already part of the "Special use domain names" registry: > > > https://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xhtml OK. > > Separately: What action should be taken if a nameserver is already > > authoritative for a zone (say, is a primary), yet it receives a catalog > update > > that now contains that same zone? This seems like a possible attack that > > should be discussed. I guess the second-last paragraph of Section 7 > covers > > this, though indirectly. > > There is text for this in section 5.2: > > "If there is a clash between an existing zone's name (either from > an existing member zone or otherwise configured zone) and an incoming > member zone's name (via transfer or update), the new instance of the > zone MUST be ignored and an error SHOULD be logged." > Ah, you're right. Thanks for the pointer. > Could I trouble you for an example of a complete sample catalog zone, > perhaps > > in BIND format, in an appendix? I can see each individual concept > illustrated, > > but it would be helpful to see them assembled someplace. > > Ack. We've added a sample zone: > > > https://github.com/NLnetLabs/draft-toorop-dnsop-dns-catalog-zones/blob/master/draft-ietf-dnsop-dns-catalog-zones.md#catalog-zone-example Thanks for this. You might consider adding some prose following the example that walks the reader through it, but this isn't strictly necessary. > We thought it couldn't harm to repeat this for clarity. Some reviewers > "stumbled" over the word "meaningless" so we rephrased this to: > > "Catalog consumers MUST ignore any RRs in the catalog zone for > which no processing is specified or which are otherwise not supported by > the implementation." > Fair enough. > > Section 4.1: > > > > Given the text in Section 3 (specifically that a catalog zone follows > the same > > rules as any other zone), is this section needed? The third paragraph > could be > > its own differently-named section, but the rest seems redundant. > > This has moved up and rephrased into one sentence: > > "A catalog zone MUST follow the usual rules for DNS zones. In > particular, SOA and NS record sets MUST be present and adhere to > standard requirements (such as [RFC1982])" > > Is that better? > Yep, thanks! I'm a little wary of redundant MUSTs (i.e., these are MUSTs that have been in effect for a really long time already), but I don't think they're harmful. > Section 4.2: > > > > The SHOULD at the end leaves implementers with a choice. Why might an > > implementer choose to do something other than what it says? Or should > this > > really be a MUST? > > As it is most likely that catalog producers and consumers hold the zone > authoritatively, TTLs shouldn't play a role as the records are not > cached anyway. However, we could imagine a catalog consumer processing > the catalog (or part of it) by performing queries. Such a consumer may > not have the choice to ignore TTLs when it is querying indirectly via a > resolver. SHOULD leaves the door open for other "kinds" of > implementations than we have now. > OK. > > Section 4.3: > > > > It doesn't say anywhere (unless I missed it) that the RRTYPEs of > properties are > > unspecified, and depend on the property. It might be good to make that > > explicit, because I kept searching for it. > > We said in the second half of the second sentence of the section: > > "with type(s) as appropriate for the respective property." > > We've changed "with type(s)" into "with RR types(s)" to make it clearer. > Thanks. > > Section 4.4.1: > > > > Regarding the last paragraph, is there any advice to pass on to > operators about > > how exactly one can tell when the COO is complete? > > Not really without querying all the secondaries, but at least > secondaries will pick it up if they either lost the notify or were down. > I suppose monitoring the network status of the secondary provider and > making sure the whole network has been up for at least the refresh time > of the catalog zone ... and then a bit more, would be a safe bet, but > it's very much dependent on the specific operational reality. > OK, I was just curious if there might be a way to close the loop here. > > Section 7: > > > > Why are the protections of zone transfers and updates only SHOULDs? > > It depends on the operational reality. Zone transfers may be using a > completely separate distribution network which is shielded from external > DNS access (with VPNs or UPDATES from an internal network or local > machine even). It is also not a MUST with zone transfers in general > which may also contain privacy sensitive or operational critical > information. > OK. Thanks for all this extra work. This is great stuff. -MSK
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
