Hi Karl, Thank you for doing this, I think this is a useful effort.
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. - 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. 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). 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. - 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) 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. Section 5.2 - Why remove the zonefile? Would it not suffice to stop serving it? Section 5.3 - Under which circumstances does the SHOULD not apply? Section B.2.1 - You could use the TTL of the respective property RRset. Section B.2.3 - I agree that perhaps even the SOA record is not needed. - If it's kept, I think it should be 1 record. - 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. 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? Cheers, Peter On 3/25/25 16:46, Karl Dyson wrote:
On Tue, Mar 25, 2025 at 05:56:14AM -0700, internet-dra...@ietf.org 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 _______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
