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.
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.
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.
- 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". :-)
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.
Best,
Peter
--
https://desec.io/
_______________________________________________
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org
