Re: [dnsdir] [DNSOP] Dnsdir last call review of draft-ietf-dnsop-dns-catalog-zones-08

[Peter Thomassen <[e-mail]>]

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/