Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-catalog-zones-06.txt

Michael StJohns <> Fri, 08 July 2022 17:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0374AC159497 for <>; Fri, 8 Jul 2022 10:01:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.78
X-Spam-Status: No, score=-3.78 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-1.876, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2IrdSI1ehBFU for <>; Fri, 8 Jul 2022 10:01:07 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::82b]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPS id A40BAC14F6EC for <>; Fri, 8 Jul 2022 10:01:07 -0700 (PDT)
Received: by with SMTP id ck6so28221083qtb.7 for <>; Fri, 08 Jul 2022 10:01:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :cc:references:from:in-reply-to; bh=qdk5QcLWaz/v4bEMULYdRE2fwjs1qm1gqaOC70i292w=; b=Js/BvrED9RLvsGloNjzxA7TcYmclAK3fE2LWweXbieiOmAAnFpcRk9OJV+jugqZMGv p9KT1w1kqcF4jgbEQg7TrV1eUOycL5hetRdhIdc0lV4G9VFcPYTs0tw7xESJQZpmFqJp SQxiJFnDpf5DKSSsA5c4kTD2HB/J3G7Ht/qMe3szmh+CXIm25SOikR4m0ueMsNrv4eM3 R0/U2CPuHPKaLh5PJmsLk5XsJGugl5qW3bZJD5vLRDXozdJMZs1Tj6X421ahGBvOXjMA dUUaPgXbmBzaWsZr0uY6xZoaI1gqDDP0X0RX4MDaegYkljtSW89qX0h7R4IBSNAGmsBH Jveg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to; bh=qdk5QcLWaz/v4bEMULYdRE2fwjs1qm1gqaOC70i292w=; b=iaSt6nwK7WNIBstslTDxyOTTk6QnLQ99ZvkxazG6HcLEYAO/G55uIv/70SOLd3sZLC VvBVz5ys0ZC11+ylyK4nE6+d4YEK/BPutoozOoh7+3sYicTSVRGzRQb3qQL58hYEn9jY 8A/jQmatJNSxHhDu7wONv0hZoBjGHQnkWcywnzWXx4F3D6eZrM8liRNeca1IlIfrotu7 k2Ad+g/HwBaDN1UGc3kFh7gjdiZGMZxUCcfqCIgbLJMUeZHIaSMB/XEbdjlam3vjG6l5 +N32DDooiRIC4A1rUcwKQNVdDdtLmQ135arDlIjVpfGq/6LHmtlPY6kXAd/1SgRpRn/S YaeQ==
X-Gm-Message-State: AJIora9KW+RbaTRPowzav/suV+i3qIyIAUmannNo7LY4K6BGjZ+EHvmY kOcPYxosDIiI0Zy2upwuqBAlMg==
X-Google-Smtp-Source: AGRyM1tFAU6GVi1QlVLma3og42ojOKG09WJkrXzoaIGVMfai+NicIXg9iF8N7Hw8ucKyidAiFuaGmw==
X-Received: by 2002:a05:6214:1cc9:b0:473:2f6:22f8 with SMTP id g9-20020a0562141cc900b0047302f622f8mr3428972qvd.22.1657299665979; Fri, 08 Jul 2022 10:01:05 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id o16-20020a05620a2a1000b006a68fdc2d18sm32384620qkp.130.2022. (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 08 Jul 2022 10:01:05 -0700 (PDT)
Content-Type: multipart/alternative; boundary="------------KeiwoRsfmAt7oVo7ufsyYC2C"
Message-ID: <>
Date: Fri, 08 Jul 2022 13:01:03 -0400
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0
Content-Language: en-US
To: Bob Harold <>
References: <> <> <> <>
From: Michael StJohns <>
In-Reply-To: <>
Archived-At: <>
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-catalog-zones-06.txt
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 08 Jul 2022 17:01:10 -0000

Hi Bob -

As I noted below, I was only using this particular text as an exemplar 
of the proper handling of SHOULD and on first glance found a section 
where I was pretty sure that .  I was kind of surprised at the phrase 
"syntactically correct DNS zones" because I'm pretty sure its a 
meaningless phrase.  A "zone master file" had syntax to be checked - 
today's database driven zones mostly don't.  But I went with that wording.

And I have no idea if the rephrasing makes sense in terms of the whole 
document - but I believe that the MUST and SHOULD usages in that 
paragraph are poorly constructed.

Later, Mike

On 7/8/2022 8:49 AM, Bob Harold wrote:
> On Thu, Jul 7, 2022 at 6:21 PM Michael StJohns 
> <> 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
>>>     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:
>>>     There is also an HTML version available at:
>>>     A diff from the previous version is available at:
>>>     Internet-Drafts are also available by rsync at