IETF Logo Mail Archive

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

"Wessels, Duane" <dwessels@verisign.com> Fri, 22 April 2022 20:51 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 5A9243A1995 for <dnsop@ietfa.amsl.com>; Fri, 22 Apr 2022 13:51:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.108
X-Spam-Level:
X-Spam-Status: No, score=-2.108 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, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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 usWDew6saBej for <dnsop@ietfa.amsl.com>; Fri, 22 Apr 2022 13:51:11 -0700 (PDT)
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 A1F353A1993 for <dnsop@ietf.org>; Fri, 22 Apr 2022 13:51:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=2366; q=dns/txt; s=VRSN; t=1650660672; h=from:to:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version:subject; bh=tAQB2rySLdj+fQ8QgiAtdypLnHu53VOVVQdrnR7FksU=; b=llniEpeKx5lW9X0jau8MUWy8SYuDUqa9vLfjkH29emcF4+V3U1e6rSQv Qd/h7dceIHRFK5p3fzqe94JBSAZ8mFkuCLG5rBLcJbgiYHudVIIBbKLUx aEaUEmpYI87RymrRfsGzAjV1CaPrPGSHJjkr4flpBI49l66rV8sVl/vaH FbcEU55xdVRkS9v0E0aqVC9cqheBrv/2IAIu/bAbtnAVCV4CUxz0qWcm8 Do1LYUKNQtGWilSYE0thwmKsYhWDzxbxsux6ZYW0C5SmN84/A54L2iQll NrcwdhasC0HQt2IlyqxUtPQ0MIZ5ZPHE/0pNSuAJZIoumOudqY5TWDIbt w==;
IronPort-Data: A9a23:x9v8Uq0I6+uBSf9SQPbD5Xpzkn2cJEfYwER7XKvMYLTBsI5bpzAFm zAcWTzQbP2KYGejed9/atjk8UsO65bUyoVhSwRuqSg9HnlHl5HIVI+TRqvS04F+DeWYFR46s J9OAjXkBJppJpMJjk71atANlZT4vE2xbuKU5NTsY0idfic5DnZ54f5fs7Rh2NQw3YLjW1nlV e7a+KUzBnf0g1aYDUpJs8pvmDs31BglkGpF1rCWTakjUG72zxH5PrpGTU2CByKQrr1vIwKPb 72rIIeRpTqFokh3WrtJpZ6gGqECaua60QGm1CIKC/D66vRIjnRaPq0TbJLwZarL4tkgch8YJ Nhl7PSNpQkV0qLko70RQSVdEn5EZLx3qe/kKmm5i/aiwBiTG5fs660G4EAeF7c+o9lRLFEWr 7oGIzcXdlaKi6So2qm9DOJrg6zPLuGyZMVG5SomlGyCS6p3KXzAa/yiCdtw0Cg9ndtDGe32e ccDaCFuYxKGaBpKUrsSIMtixbbz2iOvG9FegHmemIgy+UrS9gNsibnJa4blRPnab8oAyy50o UqDpQwVGCoyONqEziKt83+wiKnIhyyTZW4JPLei8Kd1hlCDnjZWEwMME166uryzjQi0QdQGb VIO4Sxopq83nKC2cuTAs9SDiCbslnYhtxB4SYXWNCnlJnLo3juk
IronPort-HdrOrdr: A9a23:pFPcG6pV9PhD3f/3wfflSr4aV5ryeYIsimQD101hICG9Kvbo8v xHBJwgpGXJYUUqKRUdcLe7SdS9qBLnhOVICOYqXItKMDONhILsFvAB0WKA+UydJ8SdzI5gPM 5bGsAUNDSzNykYsS+Q2mWF+qMbruVvh5rGuQ6x9RpQpEpRGsZdBk9Ce2Cm+t0ffng+OXMWLu vl2vZ6
X-IronPort-AV: E=Sophos;i="5.90,282,1643691600"; d="scan'208";a="14193428"
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_256_GCM_SHA384) id 15.1.2375.24; Fri, 22 Apr 2022 16:51:09 -0400
Received: from BRN1WNEX01.vcorp.ad.vrsn.com ([10.173.153.48]) by BRN1WNEX01.vcorp.ad.vrsn.com ([10.173.153.48]) with mapi id 15.01.2375.024; Fri, 22 Apr 2022 16:51:09 -0400
From: "Wessels, Duane" <dwessels@verisign.com>
To: "dnsop@ietf.org" <dnsop@ietf.org>
Thread-Topic: [EXTERNAL] [DNSOP] I-D Action: draft-ietf-dnsop-glue-is-not-optional-05.txt
Thread-Index: AQHYVoeiKNaEXT0iG0y1qLwNITrnrKz8q2AA
Date: Fri, 22 Apr 2022 20:51:08 +0000
Message-ID: <B0580209-5C58-4190-A7B6-E17701A3D253@verisign.com>
References: <165065927798.9371.1300162473253550749@ietfa.amsl.com>
In-Reply-To: <165065927798.9371.1300162473253550749@ietfa.amsl.com>
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: <780763B8F056374696A25595C8654AFC@verisign.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/ab7VxPP0LNT0sia0Wm1_hQdPqmI>
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-glue-is-not-optional-05.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, 22 Apr 2022 20:51:17 -0000

There are three noteworthy changes from the previous version of this draft:

1. We no longer use the term “referral glue”.

2. Instead of introducing new (and likely confusing) terms such as “sibling glue” and “in-domain glue” we now refer to these as “glue for sibling domain name servers” and “glue for in-domain name servers”.

3. Expanded the introduction paragraph that talks about not placing requirements on data in zones or registries (as suggested by Ralf).

DW


> On Apr 22, 2022, at 1:27 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           : DNS Glue Requirements in Referral Responses
>        Authors         : M. Andrews
>                          Shumon Huque
>                          Paul Wouters
>                          Duane Wessels
> 	Filename        : draft-ietf-dnsop-glue-is-not-optional-05.txt
> 	Pages           : 12
> 	Date            : 2022-04-22
> 
> Abstract:
>   The DNS uses glue records to allow iterative clients to find the
>   addresses of name servers that are contained within a delegated zone.
>   Authoritative Servers are expected to return all available in-domain
>   glue records in a referral response.  If message size constraints
>   prevent the inclusion of all in-domain glue records, the server MUST
>   set the TC flag to inform the client that the response is incomplete,
>   and that the client SHOULD use another transport to retrieve the full
>   response.  This document updates RFC 1034 to clarify correct server
>   behavior.
>

v2.8.7 | Report a Bug | By Email