Hi David,
Response inline at the bottom.
Op 03-01-2023 om 19:42 schreef Blacka, David:
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?
Setting up a catalog on the secondary is a manual step anyhow (see
Section 6. second paragraph en the third paragraph of Section 3.).
Catalogs are assumed to be associated with a set of configuration (third
paragraph of section 3) which is predefined (perhaps while configuring
for consumption for that catalog) on the secondaries. Part of this set
of configuration for secondaries are the primaries and TSIG keys to use.
Secondary name servers can have multiple catalog zones configured and be
a consumer for them, each catalog zone for a different set of primaries
(and TSIG keys).
The (predefined) set of configuration can furthermore be changed per
individual member zone within a catalog basis with the `group` property.
Also, a member zone can be migrated to a different catalog hosted on the
same secondary which is associated with a different set of predefined
configuration.
Do you think this needs to be stated more explicitly in the draft?
For the record: BIND9's implementation does provide custom properties
for primaries, the names of the TSIG keys to use, and query and transfer
ACL, but the other implementation do not as far as I can see in the
documentation for each (co-authors please correct me if I'm wrong).
Many thanks for you review David!
Cheers,
-- Willem
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
