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

Joe Abley <> Fri, 08 July 2022 13:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A2F48C157908 for <>; Fri, 8 Jul 2022 06:33:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.104
X-Spam-Status: No, score=-2.104 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, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, 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 (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id GIeE56_Er5_s for <>; Fri, 8 Jul 2022 06:33:09 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::12f]) (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 D00A6C14CF01 for <>; Fri, 8 Jul 2022 06:33:09 -0700 (PDT)
Received: by with SMTP id b12so186332ilh.4 for <>; Fri, 08 Jul 2022 06:33:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=y+pvIJ2eYUY+Trs92hWxHJiMJWHjnSEk3Blc+uCEH6c=; b=H1H9wqQlLCT7N0H9aSvmZdwKl57iUMIAkSwQmu2qZF2iaVJRGLncbK08r1l+E76aSL DI2q6mlJLzF83z8BbQlej7lafD3VWDl7+z5VWN7ipGaEbkrP7ZBt3I0u4MVIpStFPp3E 2Dn/rEZXXwxMWiMqD12ebOT9yXZ6i1rU2f+GQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=y+pvIJ2eYUY+Trs92hWxHJiMJWHjnSEk3Blc+uCEH6c=; b=TuuKzs/qmR6kXgKjrmV4h0NF6+7qVsUGJNioa69MLbvTrc1pwd8Y2p/O/L+B55XvAo Cw7d+Qzs9IYj3tFmraT2E7Kzmr1k4Cgn8SQxeZBw2kyntbC7ApXw9HqFY3Vf+wkzp7SW g88O0vqyJxpfKEgDNe5Y3moEnMdh85J6DVmNkfh5mSkvAIEMdzBgtWglGtuBt9Oi0QKT PEE4jzCuGXhywXepm8x+huFQNszHJozFUmjPxGvBBAPL+K59QUqkrlkMr3H43univKBU LYp5oRkurZfwl2fRCiAFvnMGeC9OInCNXFG3rAHQHQwOMeWjLN1eRNNr149CGI8WujBy DlwQ==
X-Gm-Message-State: AJIora+OTZQxyoAkv7lnEdnmH9d2Sq4emvkSDemtSoOE/UVE6pmv1hyE 08UKxPXN2Z4fXqseHG6U0kOPxg==
X-Google-Smtp-Source: AGRyM1tgMDZMiU8u/ne1Y8f2bYPv9lALuSOD+9I+QRccg0nBhSL4ONQYZHo8oSaXbBlPyLsJgLL0Dw==
X-Received: by 2002:a05:6e02:1bc4:b0:2da:7a81:1c9a with SMTP id x4-20020a056e021bc400b002da7a811c9amr2046572ilv.213.1657287188825; Fri, 08 Jul 2022 06:33:08 -0700 (PDT)
Received: from ( []) by with ESMTPSA id j4-20020a056e02218400b002dc366ae7easm2654352ila.74.2022. (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 08 Jul 2022 06:33:08 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
From: Joe Abley <>
Mime-Version: 1.0 (1.0)
Date: Fri, 08 Jul 2022 09:32:58 -0400
Message-Id: <>
References: <>
Cc: Michael StJohns <>, IETF DNSOP WG <>
In-Reply-To: <>
To: Bob Harold <>
X-Mailer: iPhone Mail (19F77)
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 13:33:13 -0000

On Jul 8, 2022, at 08:50, Bob Harold <> wrote:

> I thought the catalog zone was required to be a valid zone. 

I think it might be worth exploring what "valid zone" might mean. 

All consumers of catalogue zones digest the whole zone as an atomic unit; they don't retrieve it piecemeal or walk the zone. To retrieve a zone you need prior knowledge of a server that hosts it. While I suppose it's possible to identify such a server by means of referrals, I'm not aware of anybody who thinks that is sensible. So there is no need for a functional zone cut above the catalogue zone; the zone can exist in a disjoint, isolated namespace. 

More generally, a zone can be syntactically valid without the servers specified in its apex NS set existing in the global namespace or being reachable, or without an apex NS set at all. The only RR required for a zone to be valid is an SOA at its apex (but see the trailing comment in this reply). Implementations intended for general use might still complain about the absence of an apex NS set for reasons of (quite reasonable) local policy. 

So I think it's ok and expected for a catalogue zone to be weird, but that doesn't necessarily make it invalid. 

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

If local policy requires an apex TXT record containing a version control string, that might be a local requirement. I think the presence of an NS set is similar. I don't think all possible local requirements need to be anticipated in this draft, although common or expected ones might reasonably benefit from a mention.

> Do the RFC's require an NS record?

"The RFCs" and "require" in the context of the DNS is more usually a matter of religion than science. See above for examples.