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

Bob Harold <> Fri, 08 July 2022 12:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B37D0C157B55 for <>; Fri, 8 Jul 2022 05:50:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.105
X-Spam-Status: No, score=-2.105 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 XD0qKB7JTJxc for <>; Fri, 8 Jul 2022 05:50:12 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::1136]) (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 73DF4C14792F for <>; Fri, 8 Jul 2022 05:50:12 -0700 (PDT)
Received: by with SMTP id 00721157ae682-31caffa4a45so125472777b3.3 for <>; Fri, 08 Jul 2022 05:50:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google-2016-06-03; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=pfBzsvPUNzH4e+PUGmMU9bJ3igI61pfcuaMnKGdRIfE=; b=kU2lmPJB7nlumRJheyDOawvmTnKHCNg87AVH++8M3RpNlqZ3bS4WQWldPUzP1+m2lo Y1NeP9q6XV8s7PZJKw7a9XHhu6cAHtA07Lx77UmaG0JIoIeXdK6Oa5nDLPV6y1GAF7tA QaIhr0KITV1TH7BOugP3hJwBH6ijCIEmmFoLk2FjIaoNfAnUPKV3NHmfaccCdoReMKHk mYNw2Uo+XuRtt/kRaIJTCtREG2HTD7yhqFXXd8reGwmxuFRxkExLX5/jCc4/b5x/ME54 v2dR8WPa8DeinqSDpMIgm+rhbHIJqvdQX5sMAh/xnGJi7DyMs/acxVu+iMh/JQkoqWyu qLWA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=pfBzsvPUNzH4e+PUGmMU9bJ3igI61pfcuaMnKGdRIfE=; b=VbDjPnL7cZ0VnOVjvNtW/BON/KVXIwvvIpMTyLTzEF5A4rQ1ahsoyb5VlmlpwqeGtD r4kyNPuAv8FHGRtY3kOYlg10yM/9Ozkw9Uw8AW6wWVZPdfgfr0Px5s7UWFwmP2/KdUqC o70rCq44Vhi/X4uUM/+mxzRU/Um8q3otc3rIJOQu9p/OOMcViGLibTcHO3nS5icpgNzI PXq4QdGq9Qt3NjOgm2K2karv0q7pJUsC/p99h8uuICw6wxqbXG1hNtyRzONBCB+Ya74e hFhnSguodniMwmyuRZcbMnM0D9nrH8AZCv4d21cc8s4ry/uF6n83k34fgFeoIbT/5yn7 sjEg==
X-Gm-Message-State: AJIora9RNY9y8PxKVMFqS31bYQb8iw5rOzLIeFSyDLppxleru+mC+pyf ZM/yYztWEQroECvv952RiS89hsQxoTFWbU66BFAczBlLf2k=
X-Google-Smtp-Source: AGRyM1u0pFnJrL9GVl23kMUYW+UCPJYMIKqsrIYd7hVmGk6RbXWQZ1yHEv4F8OuzbrL7L0pT8MZ5rLcT+va9fROcu6E=
X-Received: by 2002:a81:39c3:0:b0:31c:e041:da92 with SMTP id g186-20020a8139c3000000b0031ce041da92mr3858994ywa.188.1657284610801; Fri, 08 Jul 2022 05:50:10 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: Bob Harold <>
Date: Fri, 08 Jul 2022 08:49:59 -0400
Message-ID: <>
To: Michael StJohns <>
Content-Type: multipart/alternative; boundary="00000000000084ddaf05e34aa475"
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 12:50:16 -0000

On Thu, Jul 7, 2022 at 6:21 PM Michael StJohns <>

> 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
> 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