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
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
