On Thu, Apr 24, 2025 at 06:46:19PM +0200, Peter Thomassen wrote: > Hi Karl, > > On 4/24/25 18:31, Karl Dyson wrote: > > > - Is the expectation that no member zones of the catalog were already > > > created? If some members have pre-existing zonefiles, in particular a > > > zone with in-bailiwick nameservers, that might alter requirements on the > > > presence of the `ns` parameter. > > > > The intention is that if a zonefile exists for a new member zone, then > > it would be left alone. > > In that case, the following text from 3.4 needs fixing: > > If the nameservers are in-bailiwick of a zone in the catalog, and an > address is not specified, this would result in a zone that will not > load - this denotes a broken catalog zone. > > .... because in fact, the zone already exists and loads. >
It does, howwver, I'm pondering the zone reset bit in 5.3 in that the zone would be reset if the catalog <unique-n> were changed per 5.4 in RFC9432, at which point the details are needed for the re-creation of the zone. > > > > Section 3.4.1 > > > - I'm not sure what the `ns` parameter TXT record should contain as a > > > value: you refer to RFC 1035 Section 3.3.11, which describes the wire > > > format. Do you want to put "name=\003ns1\007example\003com\000" in the > > > TXT record? > > > - A similar concern applies to the first two SOA fields (Section 3.3.1). > > > > > > > I was attempting to be clear that the value specified should be the > > value that you would normally put in the RDATA of an NS record in a > > zone. I'd expect, per the example, to see "name=ns1.example.com." > > But that is my point. The NS RDATA contains no ASCII dots, while the TXT > example you just gave contains ASCII dots. > Ah sorry, I missed that. Text updated, thank you. > This is the difference between wire format and presentation format. When you > refer to RFC 1035 Section 3.3, you end up with wire format. You probably want > presentation format, which is in Section 5 of that RFC. > > > > Section 3.4.2 > > > - The use of normative language here is inconsistent: The draft states > > > that both ipv4 and ipv6 parameters are OPTIONAL (period!) and later says > > > they MUST be specified under certain circumstances. > > > > The intention was that they could be omitted if the nameservers > > are not in-bailiwick, but that at least one needs to be specified > > if the accompanying glue need to be created for in-bailiwick > > nameservers. > > > > I had tried to make this clear in 3.4.2 paragraph 2...? > > Yes, I know :-) But it's not clear. If the OPTIONAL is conditional, then that > normative sentence should include the condition. For example, > > NEW > At least one of the `ipv4` and `ipv6` parameters MUST be provided if > [...]. Otherwise, both parameters are OPTIONAL. > Ah, I see what you mean; text updated, thank you. > > > - I note that the `ipv6` format explicitly is presentation format, > > > whereas for `ipv4` it's unclear (the referenced RFC section lists both). > > > (cf: `ns` comment) > > > > Again, just trying to be clear that an IP of the relevant family is > > expected, and tried to reference (what I thought was) the appropriate > > RFC(s). Happy to remove this if wording such as "...value of the 'ipv6' > > parameter MUST be a valid IPv6 address..." (and similar for IPv4. > > As above, I think you probably want to say "presentation format". :-) > Text updated, thank you. > > > Section 5.2 > > > - Why remove the zonefile? Would it not suffice to stop serving it? > > > > > > > This could be optional subject to the implementation's configuration... > > > > I was thinking along the lines of current secondary servers, which > > cease serving the zone and remove the zonefile when a member zone is > > removed from the catalog. You likely don't want the files left on the > > filesystem, as you'd then need to go tidy them up? > > Perhaps someone would like to retain the history for a while. Unlike on a > secondary, when the primary removes the zone, it's really gone. > Agreed. I've altered the text to be a "must be removed unless configuration says otherwise" but am open to switching it to default to retaining it unless the implementation's config says to nuke it. > Best, > Peter > Thank you again for your time and replies. Best wishes, Karl > -- > https://desec.io/ -- Karl Dyson _______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
