On Thu, Jul 7, 2022 at 6:21 PM Michael StJohns <m...@nthpermutation.com> wrote:
> On 7/7/2022 5:32 AM, Willem Toorop wrote: > > Dear dnsop, > > This draft describes a mechanism for automatic provisioning of zones > among authoritative name servers by way of distributing a catalog of > those zones encoded in a regular DNS zone. > > The version's focus was finalizing for Working Group Last Call. > We made sure that all MUSTs in the document have a companion description > that tells what to do if that MUST condition is not met. Also the > `group` property restrictions have been loosened to accommodate multiple > sets of catalog consumers offering different sets of group properties. > > Not to be a pedant and having not read the document, don't you mean > "SHOULD" above rather than "MUST"? MUST's are absolute requirements that > should have no wiggle room. SHOULD's are the requirements where you > probably need to explain what to do if the condition isn't met. > > One brief example taken from your document (section 4.1): > > Catalog consumers SHOULD ignore NS record at > apex. However, at least one is still required so that catalog zones > are syntactically correct DNS zones. A single NS RR with a NSDNAME > field containing the absolute name "invalid." is RECOMMENDED > [RFC2606][RFC6761]. > > Instead: "Catalog consumer MUST ignore the NS record at the apex of the > catalog zone. Catalog zones SHOULD include a single NS RR with a NSDNAME > containing the absolute name 'invalid.', but consumers MUST NOT error out > if this is not present. Non-catalog clients will take an error as expected > when retrieving the zone. Non-catalog-aware servers may fail to load or > serve the catalog zone if this NS RR is absent." (The "will" and "may" in > the last two sentences are lower case as they are explanatory and not > requirements. The last sentence explains the probable result of omitting > the NS RR.) > > My $.02. > > Mike > > > I thought the catalog zone was required to be a valid zone. We certainly should not be requiring changes to the code that verifies a valid zone. Is an NS record part of the validation in some DNS code bases? If so, it should be mandatory. Do the RFC's require an NS record? -- Bob Harold > > The authors consider this version to be complete to the best of our > ability and we'd like to ask the working group to proceed with this > document for Working Group Last Call. > > > Op 07-07-2022 om 11:03 schreef internet-dra...@ietf.org: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Domain Name System Operations WG of the IETF. > > Title : DNS Catalog Zones > Authors : Peter van Dijk > Libor Peltan > Ondrej Sury > Willem Toorop > Kees Monshouwer > Peter Thomassen > Aram Sargsyan > Filename : draft-ietf-dnsop-dns-catalog-zones-06.txt > Pages : 20 > Date : 2022-07-07 > > Abstract: > This document describes a method for automatic DNS zone provisioning > among DNS primary and secondary nameservers by storing and > transferring the catalog of zones to be provisioned as one or more > regular DNS zones. > > > The IETF datatracker status page for this draft > is:https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-catalog-zones/ > > There is also an HTML version available > at:https://www.ietf.org/archive/id/draft-ietf-dnsop-dns-catalog-zones-06.html > > A diff from the previous version is available > at:https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-dns-catalog-zones-06 > > > Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts > > >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
