Re: [DNSOP] Call for Adoption: RFC8499-bis

Tony Finch <dot@dotat.at> Tue, 10 November 2020 14:49 UTC

Return-Path: <dot@dotat.at>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DE3D3A0FD1 for <dnsop@ietfa.amsl.com>; Tue, 10 Nov 2020 06:49:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZafRe7aLU5Rs for <dnsop@ietfa.amsl.com>; Tue, 10 Nov 2020 06:49:40 -0800 (PST)
Received: from ppsw-40.csi.cam.ac.uk (ppsw-40.csi.cam.ac.uk [131.111.8.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5CD03A1009 for <dnsop@ietf.org>; Tue, 10 Nov 2020 06:48:57 -0800 (PST)
X-Cam-AntiVirus: no malware found
X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus
Received: from grey.csi.cam.ac.uk ([131.111.57.57]:37632) by ppsw-40.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.138]:25) with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) id 1kcUx4-000r7w-k9 (Exim 4.92.3) for dnsop@ietf.org (return-path <dot@dotat.at>); Tue, 10 Nov 2020 14:48:54 +0000
Date: Tue, 10 Nov 2020 14:48:53 +0000
From: Tony Finch <dot@dotat.at>
To: dnsop@ietf.org
Message-ID: <alpine.DEB.2.20.2011101342180.32156@grey.csi.cam.ac.uk>
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/5bKXkqzCyGE1NuUko9M6wXLD5bI>
Subject: Re: [DNSOP] Call for Adoption: RFC8499-bis
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Nov 2020 14:49:43 -0000

I recently noticed that the bailiwick-related definitions are wrong and
muddled.

I have always understood in-bailiwick to mean that a nameserver name is a
subdomain of its zone apex. That is, exactly the cases where glue is
required by the DNS protocol. The term comes from the discussion of
gluelessness at http://cr.yp.to/djbdns/notes.html - "RFC 1034 specifically
requires glue for referrals to in-bailiwick DNS servers."

RFC 8499 seems to use "in-domain" for this situation, which is not a term
I have seen anywhere else.

The question of sibling glue is different from whether nameservers are
in-bailiwick. It comes up in questions about registry policies rather than
DNS protocol needs: whether or not a registry requires all nameservers
that are subdomains of the registry domain(s) to have addresses, even in
cases where the DNS does not need glue.

The description of siblings in RFC 8499 is muddled, because it is unclear
when it is referring to a nameserver name or a zone name, and it's
unclear when it is talking about a child zone or their shared parent zone.
And the nameservers themselves aren't siblings; they are nephieces or
niblings or something like that.

I suggest:

  * Sibling zones: two zones whose delegations are in the same
    parent zone.

  * Sibling glue: addresses of nameservers that are in a sibling zone.
    Sibling glue is usually the glue that the DNS would require for that
    sibling zone, but in some cases the requirement lies elsewhere, for
    example

	one.example.	NS	nsa.two.example
	one.example.	NS	nsb.two.example
	two.example.	NS	ns0.two.example
	two.example.	NS	ns1.two.example

   The DNS protocol does not require sibling glue for the one.example
   nameservers, though glue addresses might be required by .example
   registry policy.

Tony.
-- 
f.anthony.n.finch  <dot@dotat.at>  http://dotat.at/
the fundamental values of liberty, equality, and community