Re: [DNSOP] Another attempt at consensus on the bailiwick discussion

"Wessels, Duane" <dwessels@verisign.com> Wed, 15 December 2021 21:17 UTC

Return-Path: <dwessels@verisign.com>
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 DA3E93A10A4 for <dnsop@ietfa.amsl.com>; Wed, 15 Dec 2021 13:17:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verisign.com
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 2eOWwGiW22aa for <dnsop@ietfa.amsl.com>; Wed, 15 Dec 2021 13:17:44 -0800 (PST)
Received: from mail4.verisign.com (mail4.verisign.com [69.58.187.30]) (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 093453A10A3 for <dnsop@ietf.org>; Wed, 15 Dec 2021 13:17:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=2046; q=dns/txt; s=VRSN; t=1639603064; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=WhwnO++AgRBPEiz8ALAmauiVFrA9xFfWIprTcqLZGOE=; b=Gdx1nkSRhpw+JpUQlAj/Q1PWxzqqKcChRqkK1dEltlWKirxq35azoVhu 8LMcTKvrq9yToz0678ocOfiqLEosAEmebYzADCXL7CRhDx79hQgP8J1M3 4m1Tgpp5F9BvwVRyCikrGx3LNldCwxwaRnfqIwLCfrWfJ/kknMnCHHkpc zSVGyT6boFm07r9gWhVC2y1DMsOVQUk3jCmhP+pIRixd44gYKbABTOXyQ ghzuwlV1Duu2JGxNWd5CkUiW/ZwkwcnwIzYUo123E5aqcL+eTfcEOgoMO FMHcGNcf7nEI98MJWn0nywcjcZKnoS/+Pqt7wbFPbsAwv1PC0pGUTyn0e g==;
IronPort-Data: A9a23:F9EeuquqgxCJuamMZerhDWTBh+fnVM1cMUV32f8akzHdYApBsoF/q tZmKW2AM//fNzfxft1zYNmx9xwC68XSmoU3TQY5+C03EiJA9ZOVVN+UEBz9bniYRiHhoOKLz Cm/hv3odp1coqr0/0/1WlTZQP0VOZigHtIQMsadUsxKbVIiGHdJZS5LwbZj29cy2IXhWGthh PupyyHhEA79s9JLGj9Mg06zgEsHUCPa4W5wUvQWPJinjXeG/5UnJMt3yZKZdhMUdrJp8tuSH I4v+l0ZElTxpH/BAvv9+lryWhNSHu6KZWBigFIOM0SpqkAqSiDfTs/XnRfTAKtao2zhojx/9 DlCnb/gWQMAOIyRpNoMAztkPSZPI/Jv94aSdBBTseTLp6HHW1HW5axRKmwGZdde5O1wG3kI/ PBeNioWaFaIgOfeLLCTE7Eq35t4apC2Z8VD6xmMzhmAZRoiaZzcTr7R6NtD9Ck9nMFVHPnYI cEebFKDaTyZOkIRagdJVvrSms+ZplT9LCQHpG7EirI8uEbBzAcp1KDUZY+9ltuiAJ89clyjj m7A5GPhKhAXKNLZziCKmk9AncfFhyWiR4QfBOXis+V0mhuWx3dWAhpQX0G9+L+nkFW4HdlYL iT45xYTkET7z2TzJvGVYvFyiCfsUsI0MzaIL9AH1Q==
IronPort-HdrOrdr: A9a23:76uGp6oUZtCtn8prHikCTyAaV5r2eYIsimQD101hICG9Ffbo8v xG/c5rtyMc5wxwZJhNo7690cq7Lk80nKQdibX5Vo3SPzUO1lHIEKhSqaXvxDH6EzDz+6p3xc 5bH5RWOZnVAUJhhcj3pCu1A78bquWvweSNif3Fx3lgCTt2bbpthj0VNi+AHlZoSBJ9CZ01KZ qZ6qN8zAadRQ==
X-IronPort-AV: E=Sophos;i="5.88,209,1635220800"; d="scan'208";a="11768866"
Received: from BRN1WNEX01.vcorp.ad.vrsn.com (10.173.153.48) by BRN1WNEX02.vcorp.ad.vrsn.com (10.173.153.49) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.7; Wed, 15 Dec 2021 16:17:42 -0500
Received: from BRN1WNEX01.vcorp.ad.vrsn.com ([fe80::a89b:32d6:b967:337d]) by BRN1WNEX01.vcorp.ad.vrsn.com ([fe80::a89b:32d6:b967:337d%4]) with mapi id 15.01.2375.007; Wed, 15 Dec 2021 16:17:42 -0500
From: "Wessels, Duane" <dwessels@verisign.com>
To: dnsop <dnsop@ietf.org>
Thread-Topic: [DNSOP] Another attempt at consensus on the bailiwick discussion
Thread-Index: AQHX8fkyq6YESoxwdky9QryHlzaPaw==
Date: Wed, 15 Dec 2021 21:17:42 +0000
Message-ID: <2009A9A9-4CF3-4AB6-8D6B-3474B15F0328@verisign.com>
References: <B08E9361-B97B-4862-861C-4EF628C85E50@icann.org> <bb61304c-6ef9-7850-3dbb-19b624bc07b@nohats.ca> <60a11d97-8be4-91e-4880-999c1a57a75b@dotat.at> <FC138247-7BA2-4CCA-8E6C-A06423236A81@icann.org>
In-Reply-To: <FC138247-7BA2-4CCA-8E6C-A06423236A81@icann.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3654.120.0.1.13)
x-originating-ip: [10.170.148.18]
Content-Type: text/plain; charset="utf-8"
Content-ID: <F681B2B5F62B48499AEAE7AFB2BC0B1D@verisign.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/P5khW7EZ04Rg1-dAglrUkJo6-5Y>
Subject: Re: [DNSOP] Another attempt at consensus on the bailiwick discussion
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: Wed, 15 Dec 2021 21:17:49 -0000

Despite what the subject line says, I’d like to follow up on the discussion about glue from today’s interim meeting.

First, I think the definition of glue given in RFC 2181 is problematic in a number of ways.  It is overly broad (e.g., "any record ... that is not properly part of that zone” and "any other stray data that might appear”).  It essentially says that all non-authoritative data is glue, including NS, which is wrong IMO.

If we can ignore what 2181 says, then the question is whether or not glue is limited only to addresses.  Historically it has only meant addresses, since those address RRs were required for zones with in-domain name servers.  There are some new proposals in DPRIVE to publish more record types in parent zones and have them considered as glue.  This has obvious implications server behavior given the glue-is-not-optional draft.

On one hand I think it would be a lot simpler to just say that only address records can be glue.  But I’m not sure that is defendable given the directions things are going.  Here’s a definition of glue that I came up with:

Glue is non-authoritative data in a zone that is transmitted in the additional section of a referral response on the basis that the data might be necessary for resolution to proceed at the referred name servers.

I also feel like we might be heading in a direction where there would need to be a registry or some standardization of which RR types can be treated as glue.

DW