> On Jan 3, 2023, at 12:48 PM, Peter Thomassen <peter@xxxxxxxx> wrote: > > Caution: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. > Hi David, > > Thank you for your review. Please see inline. Thanks! Also see inline. > > On 12/27/22 18:14, David Blacka via Datatracker wrote: > >> 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) I looked at your changes, and I think those updates work for this. > >> 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.) Also great! > >> 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. Ah, I wasn’t clear. I understand the overall use case for the catalog zones, but there were so few non-custom properties I wondered if one could effectively use catalog zones without them. I was expecting a few standard properties describing (e.g.) what the secondary should use as masters and what TSIG key to use. That is, I can see you must give the zone name for the given zone, but nothing else seems to be required. Did I miss some text that describes what is expected to happen by default?
<<attachment: smime.p7s>>
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
