IETF Logo Mail Archive

Re: [DNSOP] I-D Action: draft-ietf-dnsop-glue-is-not-optional-00.txt

"Wessels, Duane" <dwessels@verisign.com> Fri, 05 June 2020 17:37 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 378793A0B4C for <dnsop@ietfa.amsl.com>; Fri, 5 Jun 2020 10:37:59 -0700 (PDT)
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 MEwjJ6Tn0P3R for <dnsop@ietfa.amsl.com>; Fri, 5 Jun 2020 10:37:58 -0700 (PDT)
Received: from mail3.verisign.com (mail3.verisign.com [72.13.63.32]) (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 BE7413A0B83 for <dnsop@ietf.org>; Fri, 5 Jun 2020 10:37:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=8704; q=dns/txt; s=VRSN; t=1591378678; h=from:to:date:message-id:references:in-reply-to: mime-version:subject; bh=XnkfhZ3ivR995M09c36hWJMwz/orczWy/6y95/Kzcmw=; b=FEyWa5mTvcfmlWzCi4e375sbk/NWEb4o3VavupO1ZOdQFBb7xdoEtGES gMNm9JW6EkuUDlQ+gpVi7DBI5fU8Jv/rLaThL5pK1KNOWDy9IuZIutIII ladF1zTpZhDHVi/X802k1X/pRkmZtacDW9Q6YZV9+m0CGIqQtqsTok+8p 5rQYubmQIlUaa9gSHHF0ixHmgnaDY75Wx2dJ0ngcg3bWj+TGTc4pOj4LR IhXKvz/UPqfimPMC32SMzEJ3tZmkrl0RY4FTDWcmnB+Bf1lCefINxsXp7 IJx3nJkzUJvpF3nmK1a6UdepUhlo88KCbEbdLaHFyJXqLYRaiI6wTJXyl g==;
IronPort-SDR: T9Il4mdPUz2fG2EFkW9B+xMXJ3BFwtmRuYCIuRR3JgRIOKx8+WQpLERUf72GTcp4h2hfu40vdC vyI7tQuEqNMbErwH9Twzgrqsmop49A3HMkteR8Y1kvyZlneCXSezfCa2OeUox2igxHvY1pKIaj 5d8q1r81r1Og1wrO+OCeXiDD0fKlFOdv7dPQZYRHVFFc3d7RDOLlypFGnoyc5MeQUzpalpVBak yBTyCPbKnQ8gnbe0KxlyFGkHQPrkuVQIgIne6nE9fmFPinSOqjqfVU/qDY0VoYEIbdQcDP2KOP uM4=
X-IronPort-AV: E=Sophos; i="5.73,477,1583193600"; d="p7s'?scan'208"; a="1834807"
IronPort-PHdr: 9a23:5tv3bhCPUTZ5NC0nnjaRUyQJP3N1i/DPJgcQr6AfoPdwSPX6rsbcNUDSrc9gkEXOFd2Cra4d1qyP7/urADRYqb+681k6OKRWUBEEjchE1ycBO+WiTXPBEfjxciYhF95DXlI2t1uyMExSBdqsLwaK+i764jEdAAjwOhRoLerpBIHSk9631+ev8JHPfglEnjWwba5yIRmssAncuccbjYR/Jqot1hfCv2dFdflRyW50P1yYggzy5t23/J5t8iRQv+wu+stdWqjkfKo2UKJVAi0+P286+MPkux/DTRCS5nQHSWUZjgBIAwne4x7kWJr6rzb3ufB82CmeOs32UKw0VDG/5KplVBPklCEKPCMi/WrJlsJ/kr5UoBO5pxx+3YHUZp2VNOFjda/ZZN8WWHZNUtpUWyFHH4iybZYAD/AZMOhYsYfzukcOoxW9CwmiBuzhzT5IiWP50qAh3OQtDQTG0RYgH94SrnjZqsj+OqcIUeCyyanF1TvPYPNI1jfm84jHbBQhoeqUUbltf8TR1FMgFwXbgVmetIfoOC6a1+oTvGiA9OpvS+avi3U8pgFvvDev3MYsipLIhoIazFDI7zl2wIEwJdChTkNwfNGrHodKuS6AK4t2Xt0tQ3tuuCsixLALp562cigUxZkk2xPSZf+KfpWI7xzjSuufLzl2inJkdb6hiBi/71WsxOLyWMWpzFpEoTZIn8TQu30P1xLe7s6KQeZ+8Ee5wTuDyhzf5vtZLU02m6fXMYMtz74+m5YJvknOHTf6lFjqgKOMa0kp+PSk5/76brjppZKQLZJ4hwL4P68zgMKwG/44PRILX2WD/OS806Ds8lPhTbVRi/02jrHZsJfHJcQHvqK5AxFa0oIk6xunEjqozMwWkWQHI1xddxyIjpTlN0zULPDmEfi/hE6skC9xy//cI7LtGIvNLmLYkLfnZ7py90lcyA8rwdBe4ZJbFK0BLeruVkPtrtDUEx00PgKuz+r6CNhw2JkSVG2MD6OBNaPdq16I5uYhI+mWY48VvS7wJOUr5vHwln85gkESfa2y3ZYMdnC3AO5mI0SCYXrtjdcBF30GsRY5TOzvkFGCSyJcZ26uX6Ig4TE2EJ+pDYHYRoCqmLyMxya7EYNKZmBIEFyMFm3od4rXE8sLPQO/HuEpvho/coDpdKBpgR2orwji47tqMuSS/TcX48HNzt9wsqfsmAop+DhvS4yxzmiLQis8ym8XSiQt0aRkiVJw0FaY0Kd+xfdfEIoAtLtyTg4mOMuEnKRBANfoV1eEJ4/RRQ==
X-IPAS-Result: A2E0AgC+gdpe/zCZrQpmHAEBAQEBAQcBARIBAQQEAQFAgUqBe4FKgQgKlSWDc5gIBAcBAQEBAQEBAQEDBAEvBAEBgVCCdAKCNiU4EwIDAQELAQEBBQEBAQEBBgMBAQEChlCCOykBg2IBAQEBAgF+CwIBCBguAjAlAgQTDoMYAYJcEbI3dIE0hVGFIhCBOIFTixOBQj6BESccgk0+hDYXg0iCLQSPJYkxmygDB4JZhCOCU4M/jk8dgmebWqs9g00CBAIEBQIVgWqBeXAVGksBgj4+EhcCDZFmAQcHjRN0NwIGCAEBAwmOOYEQAQE
Received: from BRN1WNEX01.vcorp.ad.vrsn.com (10.173.153.48) by BRN1WNEX01.vcorp.ad.vrsn.com (10.173.153.48) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Fri, 5 Jun 2020 13:37:56 -0400
Received: from BRN1WNEX01.vcorp.ad.vrsn.com ([fe80::a89b:32d6:b967:337d]) by BRN1WNEX01.vcorp.ad.vrsn.com ([fe80::a89b:32d6:b967:337d%5]) with mapi id 15.01.1913.005; Fri, 5 Jun 2020 13:37:56 -0400
From: "Wessels, Duane" <dwessels@verisign.com>
To: IETF DNSOP WG <dnsop@ietf.org>
Thread-Topic: [EXTERNAL] [DNSOP] I-D Action: draft-ietf-dnsop-glue-is-not-optional-00.txt
Thread-Index: AQHWOhkP+/UWVrS8BUiHODMkuBw13qjKjvOA
Date: Fri, 05 Jun 2020 17:37:56 +0000
Message-ID: <B339E4C9-5F28-41A7-99C7-5B8ECC9CF14C@verisign.com>
References: <159123820967.306.12808925210425325877@ietfa.amsl.com>
In-Reply-To: <159123820967.306.12808925210425325877@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3445.104.14)
x-originating-ip: [10.170.148.18]
Content-Type: multipart/signed; boundary="Apple-Mail=_7DD55A0E-303E-4AFC-9C05-0775C21173EB"; protocol="application/pkcs7-signature"; micalg="sha-256"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/qgJDLpEswWLJITxZs_LdKk77rQ0>
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-glue-is-not-optional-00.txt
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: Fri, 05 Jun 2020 17:37:59 -0000

The essence of this draft is the addition of once sentence to RFC 1034:

  "If glue RRs do not fit set TC=1 in the header."

I worry that this is too ambiguous.  Does it mean all glue?  One glue?  As much as will fit?

AFAIK most software today is designed to fill up the additional section with as much glue as possible.  Is the name server allowed to add only some glue RRs, even if more would fit (without truncating, or in a TCP response)?

Is the name server allowed to fill the additional with all records of one type, AAAA or A, when the resolver might only have connectivity of the other type?

There is also the question of in-domain vs sibling-domain glue.  RFC 8499 (Terminology) notes that "Glue records for sibling domains are allowed, but not necessary."  Should in-domain glue take priority over sibling-domain glue?  Can sibling-domain glue be omitted even if it would fit?

DW


> On Jun 3, 2020, at 7:36 PM, internet-drafts@ietf.org wrote:
> 
> 
> 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           : Glue In DNS Referral Responses Is Not Optional
>        Author          : M. Andrews
> 	Filename        : draft-ietf-dnsop-glue-is-not-optional-00.txt
> 	Pages           : 5
> 	Date            : 2020-06-03
> 
> Abstract:
>   The DNS uses glue records to allow iterative clients to find the
>   addresses of nameservers that live within the delegated zone.  Glue
>   records are expected to be returned as part of a referral and if they
>   cannot be fitted into the UDP response, TC=1 MUST be set to inform
>   the client that the response is incomplete and that TCP SHOULD be
>   used to retrieve the full response.
>

v2.23.0 | Report a Bug | By Email