IETF Logo Mail Archive

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

"Wessels, Duane" <dwessels@verisign.com> Fri, 05 June 2020 19:56 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 6ABC93A0814 for <dnsop@ietfa.amsl.com>; Fri, 5 Jun 2020 12:56:21 -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 HTxkFRmxh52C for <dnsop@ietfa.amsl.com>; Fri, 5 Jun 2020 12:56:17 -0700 (PDT)
Received: from mail2.verisign.com (mail2.verisign.com [72.13.63.31]) (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 CE4053A0817 for <dnsop@ietf.org>; Fri, 5 Jun 2020 12:56:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=8847; q=dns/txt; s=VRSN; t=1591386978; h=from:to:cc:date:message-id:references:in-reply-to: mime-version:subject; bh=yR8u+j4xSwIJ9ZlMPSrG8XfvLPEm4VTW5VSTRD1ANWM=; b=CieTRWpH+2dcjCLimqS079lURqFZA1nYbhiP8/+JBMU4po2MHO2sPnTC wONRaviOjiI8aAXM/awLYMgEHPIm/hYgp337XGoAv6Y5Rr7NdsHr7ORpS LWzEyfux2QIMqtpTcBvtNJxoXTAp1HZHOaxWaHHE4+GmI3sdjSufvUqCe pOtw10XqtR0BjLU2Mg+m6uSUE1q+LWg2kD5HZpAnZF6GiYpb/5asfr/G4 fq69pxhHYQAvUAvYWHrjLusDSz0XE3NX0bye0DLXKg9lJceWFFhRTvrpb c6cIxdrfNaljTVl5FXIhh9dFd4FA3IIOuxxrK6PnkFxsbLiP8lWhSeE1x g==;
IronPort-SDR: LtHvyvglzNx0zG3VrV64QV4w8sJW7ZYC33Tsd3k6H0bCZ08b/+EQDvSQnVwv62J6OlajrHpWKr IqBI1z79bVKKAWTkQDNxm1cou73SHLwpbmD+dmdkMcSgCJryKxiIFh4KUEXGR6ySjNHS7+ifXp +HI5hVwp+KrIOOTSEWn3LCp1nc9qwwpiL2Wt5CN4XyHjWr5+drVjn0UyY8WxPTRlvd3L30bQSn zFcqWt4p/CvzOOmt0lnZRW/qiCTntkQVoDKK2/7rDCjafGQTZPL+e/eACFCJY6tqp/AEm3HWMo oR4=
X-IronPort-AV: E=Sophos; i="5.73,477,1583193600"; d="p7s'?scan'208"; a="1220632"
IronPort-PHdr: 9a23:jxg7dxdCc0A3BRWDJOIp4nT6lGMj4u6mDksu8pMizoh2WeGdxcWyYh7h7PlgxGXEQZ/co6odzbaP7ua5BTdLuMza+Fk5M7V0HycfjssXmwFySOWkMmbcaMDQUiohAc5ZX0Vk9XzoeWJcGcL5ekGA6ibqtW1aFRrwLxd6KfroEYDOkcu3y/qy+5rOaAlUmTaxe7x/IAi2oAnLq8UbjoVvJqksxhfXrHZDZvhby35vKV+PhRj3+92+/IRk8yReuvIh89BPXKDndKkmTrJWESorPXkt6MLkqRfMQw2P5mABUmoNiRpHHxLF7BDhUZjvtCbxq/dw1zObPc3ySrA0RCii4qJ2QxLmlCsLKzg0+3zMh8dukKxUvg6upx1nw47Vfo6VMuZ+frjAdt8eXGZNQ9pdWzBEDo66coABDfcOPfxAoof9uVUAsAe+CwevCuPhyDBGgX720rE13Ok6HgHKwAkgEsgOsHjIstn4MroZX+CvzKnPyDXOd/1a1jfj54jTaRAuv/WMXalofcHMx0cvChnKjlOOpoDrIjiY0fkCsmaF4Op7TuKglWonqxpqrzix2MgskIjJhpkUylDL8yV12po6Jdq9SENiZ9OvDZRfuT2AOYRsXsMiX39nuDw8yrAet5O2YigHxpQ5yhPcd/GKfYuF7w/jWeiRPzp2inxrdrK+ihqs/kat1PDwWMa63lpXsiZLncXBu20R2hHR6saKTv1w9Vqi1zaXzw3f9/1ILVopmafZJZMt2KM8m5odvEjZESL7nF36gLKKekk+5+Sl6fjrbq/7qpKTNIJ4kBzyP6col8eiG+o3KBIOUHKe+emk0b3j+lD2T6tSg/0tl6nZrIjaJcMGpq6lGwNV0pgs6xK4Dzq+zdkWgWEJIE9FdxyfgIbmOk3CLO7iAfehn1usly1rx+jcMrL7H5rBNGbDkK36fbZ78UJT1A0zzdVH65JVDLEOPu7zV1fsuNDEFBM1Lg65zuj9BNlg1o4TV3iDD6CdPa/KtF+H/OMvI+2CZI8Pvzb9LuAo6OPgjHAngl8dZrem3Z8MaH2jAPRpPV+ZYXv3gtcAHmcKuBAyQ/DtiF2HSTJTfWq9X7og5jEnD4KrFZ/DSZqwgLyFxiu7HppWZm5IClCJC3jocZ6JW/YQZy2IJM9hlCYIVb+7S48uzRuurhP1y6J7LurI/S0VrY/s1N5u5+3UjRE/7j10ANqB02GDVW10mXkIRzBllJx49HR011PL8a92jflRE5QH//pUVkE6MpDSyuV8I9H5UwTHONCTRwD1bM+hBGR7cd8q2NIKeAI1N8iriB2Jl36mHLIOjLGPH7Qq/7jdxHn+IYB2zHOQh/pptEUvXsYabT7uvaV47QWGQteRy0g=
X-IPAS-Result: A2ESAAAxotpe/zGZrQpmGgEBAQEBAQEBAQEDAQEBARIBAQEBAgIBAQEBQIE5AgEBAQELAYF6gUqBCAqVACWDc5gIBAcBAQEBAQEBAQEDBAEvBAEBgVCCdAKCNiU3Bg4CAwEBCwEBAQUBAQEBAQYDAQEBAoZQgjspAYNiAQEBAQIBeQULAgEIGC4CMCUCBA4FDoMYAYJcEbJLdIE0hVGFOBCBOAGBUosTgUI+gREnDBCCTT6CZwSBSxeDSIItBI8liTGbKAMHglmEI4JTkg4dnkGrPYNNAgQCBAUCFYFpgXpwFWUBgj4+EhcCDZB4bgEHjRp0AjUCBggBAQMJjjmBEAEB
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.1913.5; Fri, 5 Jun 2020 15:56:15 -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 15:56:15 -0400
From: "Wessels, Duane" <dwessels@verisign.com>
To: Paul Hoffman <paul.hoffman@icann.org>
CC: IETF DNSOP WG <dnsop@ietf.org>
Thread-Topic: [EXTERNAL] Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-glue-is-not-optional-00.txt
Thread-Index: AQHWO2sgov9vEBWaNkujzhvdZPMYDajKsvQA
Date: Fri, 05 Jun 2020 19:56:15 +0000
Message-ID: <5E86E9EE-A022-44F0-9483-F498A03C39C4@verisign.com>
References: <159123820967.306.12808925210425325877@ietfa.amsl.com> <B339E4C9-5F28-41A7-99C7-5B8ECC9CF14C@verisign.com> <E15EACC7-ACF3-4312-9D32-52E0860F668A@icann.org>
In-Reply-To: <E15EACC7-ACF3-4312-9D32-52E0860F668A@icann.org>
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=_491974A1-CEBF-4B75-872B-24C003D13F80"; protocol="application/pkcs7-signature"; micalg="sha-256"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/lt7zZQ777H5nFf3gTJiZ-pLqCQ4>
Subject: Re: [DNSOP] [Ext] 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 19:56:21 -0000


> On Jun 5, 2020, at 11:56 AM, Paul Hoffman <paul.hoffman@icann.org> wrote:
> 
> On Jun 5, 2020, at 10:37 AM, Wessels, Duane <dwessels=40verisign.com@dmarc.ietf.org> 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.

I believe this is contrary to how most authoritative DNS software works today, isn't it?

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

And that sounds like the opposite of what you suggested above?

DW

v2.23.0 | Report a Bug | By Email