Re: [DNSOP] Murray Kucherawy's Discuss on draft-ietf-dnsop-dns-catalog-zones-08: (with DISCUSS and COMMENT)

["Murray S. Kucherawy" <[e-mail]>]

On Tue, Feb 7, 2023 at 2:02 AM Willem Toorop <[e-mail]> 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