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

Paul Hoffman <> Fri, 05 June 2020 18:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 69E0F3A0AF0 for <>; Fri, 5 Jun 2020 11:56:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5IItMm4S4YiQ for <>; Fri, 5 Jun 2020 11:56:49 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F41613A0AE9 for <>; Fri, 5 Jun 2020 11:56:48 -0700 (PDT)
Received: from ( []) by ( with ESMTPS id 055IukcH023468 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for <>; Fri, 5 Jun 2020 18:56:47 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 5 Jun 2020 11:56:44 -0700
Received: from ([]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([]) with mapi id 15.00.1497.006; Fri, 5 Jun 2020 11:56:44 -0700
From: Paul Hoffman <>
Thread-Topic: [Ext] [DNSOP] I-D Action: draft-ietf-dnsop-glue-is-not-optional-00.txt
Thread-Index: AQHWO2sOMJbS3Pr5hUqVYGewAAbNHg==
Date: Fri, 5 Jun 2020 18:56:43 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
x-source-routing-agent: Processed
Content-Type: multipart/signed; boundary="Apple-Mail=_6CB90BC5-833E-4366-9891-9AB2207E8E4C"; protocol="application/pkcs7-signature"; micalg=sha-256
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.216, 18.0.687 definitions=2020-06-05_05:2020-06-04, 2020-06-05 signatures=0
Archived-At: <>
Subject: Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-glue-is-not-optional-00.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 05 Jun 2020 18:56:51 -0000

On Jun 5, 2020, at 10:37 AM, Wessels, Duane <> wrote:
> 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?

The current document is indeed ambiguous. I propose that it be changed to:
   If all glue RRs do not fit, set TC=1 in the header.

Given Duane's questions above, we can do better with another change to RFC 1034 in this document. In this same paragraph from RFC 1034, it says:
   Put whatever addresses are available into the additional
   section, using glue RRs if the addresses are not available from
   authoritative data or the cache.
That could instead be:
   Put at least one available address into the additional
   section, using glue RRs if the addresses are not available from
   authoritative data or the cache.

I don't think it is worthwhile to go into more detail about how to choose how many to put in (because RFC 1034 didn't explicitly talk about message size), or the mix of A and AAAA (because RFC 1034 didn't anticipate more than one address type).

--Paul Hoffman