On Thu, Apr 24, 2025 at 03:22:18AM +0200, Peter Thomassen wrote: > Hi Karl, > > Thank you for doing this, I think this is a useful effort. >
Thank you for taking the time to read and feedback. > > I gave the draft a read, and the overall idea seems fine. There are some > details I have thoughts about, plus the stuff you mentioned yourself in > Appendix B (which I will mostly not repeat, but these are good questions). > > Section 3.4 > - I'm not sure NS records are needed; they could be added through the > primary's record provisioning mechanism once the zone exists. -- You mention > that otherwise the zone doesn't load. That's an implementation detail, > though, and not a protocol problem. For example, while NS records are > missing, it could "load" for dynamic updates, but not for serving. Indeed; as mentioned in the "brain dump/thoughts" appendix, I'm undecided whether the catalog could, as you suggest, be kept as minimal and simple as possible, with NS omitted, and a bare SOA, on the assumption that the empty initialised zone is practically useless unless the operator follows up with some dynamic updates, and so could populate their chosen records at that time. > - 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. But I hoped to leave that up to the implementtion to be able to allow the operator to specify desired behaviour via the implemention's coniguration (see 3.2, which may not convey that as well as I'd hoped, given your question). > > 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." > 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...? > - 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. > > Section 3.4.3 > - The example has 3 key-value pairs embedded in two character strings. For > clarity, perhaps one character string per pair? > - Related: Section 3.4 says the pairs are "separated by whitespace" which is > not correct when they are in different character strings. > This may be a function of trying to format it for the narrow width: "name=ns1.example.com ipv4=1.2.3.4 ipv6=2001:db8::1" is what is expected in the RDATA. I tried to follow the convention for the examples in the catalog zones RFC (9432). > 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? > Section 5.3 > - Under which circumstances does the SHOULD not apply? > Good spot. Per RFC9432 Section 5.6, which refers to 5.4, the reset process nukes the zone, so I will change this to MUST. > Section B.2.1 > - You could use the TTL of the respective property RRset. Agreed; I pondered that and I think briefly discussed it with at least one of the reviewers, but just felt a little uncomfortable with it, so left it in the appendix hoping to get thoughts from those kind enough to review. > > Section B.2.3 > - I agree that perhaps even the SOA record is not needed. Ditto NS as you mention above. > - If it's kept, I think it should be 1 record. Agreed. > - Suggest to keep the catalog zone simple, and leave serial treatment fully > up to the primary. It needs to be able to set serials anyway for subsequent > zone updates. > Agreed. > General: > - It seems like the cat zone's init property set would apply to all zones > unless override -- but there's no negative override. Is this intended? Are > there situations where that's not desirable? > It would be possible to have a parameter that "enables" this behaviour, which if set at the global level could be negated at the member zone level, or vice-versa... > Cheers, > Peter > The word tweak for 5.3 is visible in the update at the following location, between datatracker versions: https://karldyson.github.io/draft-dyson-primary-zonefile-initialisation/draft-dyson-primary-zonefile-initialisation.txt https://karldyson.github.io/draft-dyson-primary-zonefile-initialisation/draft-dyson-primary-zonefile-initialisation.html Thanks, Karl > > On 3/25/25 16:46, Karl Dyson wrote: > > On Tue, Mar 25, 2025 at 05:56:14AM -0700, [email protected] wrote: > > > Internet-Draft draft-dyson-primary-zonefile-initialisation-01.txt is now > > > available. > > > > > > Title: Initialisation of Zone Files on the DNS Primary Server > > > Author: Karl Dyson > > > Name: draft-dyson-primary-zonefile-initialisation-01.txt > > > Pages: 16 > > > Dates: 2025-03-25 > > > > > > Abstract: > > > > > > This document describes an update to "DNS Catalog Zones" ([RFC9432]) > > > that facilitates a method for the primary server of a DNS zone to > > > create the underlying master file for member zone(s) using > > > information contained within a catalog zone. > > > > > > > Hello, > > > > I had spoken to a few folks about this idea in Dublin. I've finally > > written it all down and, after some initial review and feedback, feel > > like I've got it to a point where I'm happy to circulate more widely. > > > > There's an appendix at the bottom that aims to outline some of my > > thoughts as I was writing it, and things I think still might need > > answers. > > > > It also occurred to me as I wrote this that it might be nice to be able > > to signal to a DNSSEC signer that is also consuming the/a catalog that > > when a new zone is added, that it should create keys and begin signing > > activities. To that end, I'm writing a second draft that I'll circulate > > once I've written more of it. > > > > I'd be grateful for thoughts and comments on the idea(s). > > > > Thanks in advance, > > Karl > > > > -- > Like our community service? 💛 > Please consider donating at > > https://desec.io/ > > deSEC e.V. > Möckernstraße 74 > 10965 Berlin > Germany > > Vorstandsvorsitz: Nils Wisiol > Registergericht: AG Berlin (Charlottenburg) VR 37525 > -- Karl Dyson _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
