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

[Willem Toorop <[e-mail]>]

Hi Murray, Hi Éric,

I have added Éric on CC because he also asked for a IANA registry for 
catalog zones properties (which we have added).

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.

> (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 )


> (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."


> (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


> 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."


> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> General:
> 
> 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


> Section 3:
> 
> "Catalog consumers MUST ignore any RR in the catalog zone which is meaningless
> to or otherwise not supported by the implementation" seems peculiar.  Wouldn't
> you do that anyway?

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."


> 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?


> 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.


> 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.


> 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.


> 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.



I plan to record all the changes that have been done in the Change 
History appendix and then upload version -09 for rereview.

Best regards,

Willem Toorop on behalf of the draft-ietf-dnsop-dns-catalog-zones co-authors