Thanks Warren,
We have addressed your change requests in the freshly submitted version
-08. I'll go over them individually as well as answer your questions
inline below. (most of them copied verbatim from the PR for these
changes:
https://github.com/NLnetLabs/draft-toorop-dnsop-dns-catalog-zones/pull/54 )
Op 30-10-2022 om 11:46 schreef Warren Kumari:
AD Review: Catalog Zones.
Hi there,
Thank you for all of the work you have put into this document; I think
that catalog zones are a really useful feature, and should be documented.
Before I can start IETF Last Call, however, there are some questions
and issues that need to be addressed - the majority of these are
simply editorial changes where the document could be made clearer and
more readable, but there are also some more substantive questions /
places that need additional text.
Thank you again for writing this, and please SHOUT LOUDLY once you've
had a chance to address these and post a new version, or if you'd like
to discuss / have any questions, etc.
SSSHHHOOOUUUTTT!!!
W
----
Meta: The document has 7 authors, which exceeds the recommended 5.
While we can approve more, but it requires justification - why does
this document have 7?
To guarantee and maximize interoperability we wanted representatives of
some of the Open Source authoritative name server implementations (BIND,
Knot, NSD and PowerDNS) as well as one operator to be authors on this
draft. For two of the Open Source implementations also the persons that
did the actual implementation the protocol were added. So it is both to
express the endorsement from ISC, CZ.NIC, NLnet Labs , PowerDNS and
deSEC, as well as recognition of the actual implementers (which also
collaborated intimately on this draft).
All 7 authors contributed substantially to the draft's content.
Sec 1:
O: "... they must also add/remove the
zone from all secondaries, either manually or via an external
application."
P: "they must also add/remove the configuration for the zone from all
secondaries"
C: Just above it says that the zone is transferred using [AI]XFR.
done
O: "This can be both inconvenient and error-prone; it is
also dependent on the nameserver implementation."
C: I don't have proposed text, but it is unclear what is mean by "it".
Perhaps "... and error-prone; the configuration syntax ..."
done ("and error-prone; in addition, the steps required are dependent")
O: "This document describes a method in which the catalog is..."
C: Perhaps "list of zones" instead of catalog? Otherwise it feels a
bit like a circular definition. Just a thought...
done
O: "As zones are added to or removed from the
catalog zone, these changes are distributed to the secondary
nameservers in the normal way."
C: Well, no - it's really not "in the normal way" - the normal way is
that you edit the config file. I understand what you are trying to
say, but I don't think that this says it. I propose just "As zones are
added to or removed from the catalog zone, these changes are
distributed to the secondary nameservers." or "... this zone is
distributed to the secondary namesservers (just like any other zone)."
done similarly (also rephrased an adjoining sentence)
Sec 3:
O: "Catalog consumers MUST ignore any RR in the catalog zone which is
meaningless or useless to the implementation."
C: Ourgrgh... Can you reword this? "useless to the implementation" is
really really vague, and this *will* result in DISCUSS ballots.
done ("meaningless to or otherwise not supported by the implementation")
O: "The SOA record's SERIAL, REFRESH, RETRY and EXPIRE fields [RFC1035]
are used during zone transfer."
C: Erm, "are used" how? Perhaps either drop this sentence (it doesn't
seem to add anything), or "The SOA record's SERIAL, REFRESH, RETRY and
EXPIRE fields [RFC1035] are used during zone transfer, just like they
would be for any other zone"?
done (dropped)
Sec 4:
O: "More than one record in the RRset denotes a broken
catalog zone..."
C: Can you come up with a better word than "denotes"? To me "denotes"
implies that the user has *chosen* to do this. Perhaps "results in"?
Sorry I don't have a better suggestion.
done ("indicate"), both in Section 4.2 and in 4.4.1. -- Potential
alternatives: "signify", "are a sign of"
O: "The TTL field's value is not defined by this memo."
C: Erm... perhaos "The TTL field's value has no meaning in this
context, and [MUST/SHOULD] be ignored."? Otherwise someone will ask
what it means...
done, also swapped and merged with subsequent sentence.
Sec 4.4.2.1. Example
I think that the example is quite unclear, and it will raise more
questions than it answers -- for example, people are going to ask who
exactly parses "operator-x-sign-with-nsec3", and they will also try
and figure out where these verbs (e.g 'nodnssec') are defined. I think
that you need to clarify that the meaning of the text records are
opaque / defined between the producer and consumer. This is discussed
above ("The exact handling of configuration referred to by the group
property value is left to the consumer's implementation and
configuration."), but it's not clear in the example.
done
Sec 4.5:
"A custom property is named as follows:
; a global custom property:
<your-property>.ext.$CATZ
; a member zone custom property:
<your-property>.ext.<unique-N>.zones.$CATZ"
vs
"For
example by including the name of the implementation in the property,
e.g. like: <property-name>.<implementation-name>.ext.$CATZ."
So, which is it? '<your-property>', or '<implementation-name>'? If
these are the same thing, then that's not clear (I'd guess that this
is that the <your-property> is supposed to show that it can be
composed of <property> and <implementation>, but it's really not
clear). It's also not really clear how people should name their
properties, and some examples here might help.
done (the clarification). The naming scheme is entirely up to
implementations, so the authors think that examples are not needed.
O: "A property description should clearly say what semantics apply,
and whether a property is global, member, or both."
C: Ok, fair enough -- but this is the first mention of property
descriptions. If I write one, I'll happil say what the semantics are,
etc -- but where should I put this? Who do I shate it with? Is this
for my own internal use, or should I publish it externally? If you
have this level of suggestion, then it implies that these will be used
somewhere...
done ("A property agreement between producer and consumer should clearly
define what semantics")
Sec 6:
O: "Although any valid domain name can be used for the catalog name
$CATZ, it is RECOMMENDED to use either a domain name owned by the
catalog producer, or to use a name under a suitable Special-Use
Domain Name [RFC6761]."
C: I'm very confused. If I am Yahoo, are you saying that I *could* use
microsoft.com <http://microsoft.com/> as the catalog name? Presumably
that woould end badly.... Also, what is a "suitable Special-Use Domain
Name"? 10.in-addr.arpa <http://10.in-addr.arpa/>.? localhost.?
example.com <http://example.com/>.? Why doesn't this just say that the
catalog name MUST be under a domain owned by the catalog producer?
To answer your question. The catalog zone is not (necessarily) part of
the global name space. It is part of the control plane and not the data
plane. Using an unpublished DNS domain makes sense also to not
accidentally leak the zones in the catalog.
However operators should certainly not "hijack" just any name from the
domain space for a catalog! That's asking for trouble! We've rephrased
the paragraph to state this a bit more stronger and clearer to this:
Although any valid domain name can be used for the catalog name
$CATZ, a catalog producer MUST NOT use names that are not under the
control of the catalog producer. It is RECOMMENDED to use either a
domain name owned by the catalog producer, or to use a name under a
suitable name such as "invalid." [@!RFC6761].
Sec 7. Security Considerations
O: " Administrative control over what zones are served from the configured
name servers shifts completely from the server operator (consumer) to
the "owner" (producer) of the catalog zone content."
C: Ok, so I'm Coca-Cola, and I've contracted with DNS-R-Us to serve as
my secondary nameserver service. I have a bunch of zones (coke.com
<http://coke.com/>, fanta.net <http://fanta.net/>,
monster-energy-ultra.org <http://monster-energy-ultra.org/>), and so I
send you a catalog zone. One day I decide to send you a catalog zone
containing pepsi.com <http://pepsi.com/> (who also uses DNS-R-Us), and
hilarity ensues...
done (added a sentence saying the consumers MAY reject member zones
based on whatever criteria found suitable)
ISC is actually implementing this for BIND9, see:
https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/6650#note_318185
Let me know if you need any more changes or clarifications.
Cheers,
-- Willem
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
