Hi David,
Thank you for your review. Please see inline.
On 12/27/22 18:14, David Blacka via Datatracker wrote:
Reviewer: David Blacka
Review result: Ready with Nits
Reviewer: David Blacka
Review Result: Ready with Nits
Hi, I'm the designated DNS Directorate (dnsdir) reviewer for this document.
Overall, I think this draft is in pretty good shape. I have a nit and a few
overall comments.
First, a small typo that could be fixed. In section 7,
As catalog zones are transmitted using DNS zone transfers, it is
RECOMMENDED that catalog zone transfer are protected from unexpected
modifications by way of authentication,
should be:
As catalog zones are transmitted using DNS zone transfers, it is
RECOMMENDED that catalog zone transfers are protected from unexpected
modifications by way of authentication,
That is, "transfer" should be "transfers".
Done.
This and other changes below are part of the following PR that will be merged along with changes from other reviews: https://github.com/NLnetLabs/draft-toorop-dnsop-dns-catalog-zones/pull/55/commits
Second, some comments:
This draft is not quite definitive on whether or not Catalog Zones are directly
queryable. Instead, it strongly discourages them from being queried, but
usually using non-normative language. (The exception: the security
considerations RECOMMEND limiting who can query the zone.) I wonder if the
document would be better served with a more up-front statement on this issue?
Good point -- the text indeed was a bit hand-wavy in this regard. I modified as follows:
- Replace (with better wording) or remove "casual" (non-normative) references to DNS queries (e.g. when talking about TTL values)
- Add justification why limiting queries is RECOMMENDED (namely, to prevent unintentional exposure of catalog zone contents)
An appendix showing a full example catalog zone would be a nice addition to the
document. There are examples throughout the text demonstrating specific
concepts, however, so it isn't clear that such an appendix is strictly
necessary.
Done, based on an example from the Knot DNS documentation. (This has also been requested by other reviewers.)
Catalog zones appear to be intentionally not fully interoperable between
completely un-coordinated instances. Is this interpretation correct? I think
my basic confusion arises from not seeing what can be done with catalog zones
*without* custom properties.
This is correct.
As to "what can be done without custom properties": The main use case is provisioning and deprovisioning zones on secondary DNS servers.
Without catalog zones, the secondary has to either somehow retrieve the list of zones via an out-of-band channel, or rely on heuristic processing of indirect signals from the primary. For example, a common way for removing secondary zones has been to let them "expire": check periodically whether the primary still knows the zone, and if it doesn't for say 1 week, assume it's not a glitch and remove the zone. This scales badly (requires lots of checking queries) and also risks deleting a zone prematurely when there actually is some other kind of problem causing the primary to not respond as expected.
This is the use case in which catalog zones are expected to be interoperable. Beyond that, vendors are free to map whatever zone settings their implementation offers, by means of custom properties. Examples of this could be zone-specific rate limiting or statistics collection.
Thanks,
Peter
--
https://desec.io/
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
