[dd] Potential charter for a DNS Delegation Working Group

Paul Hoffman <paul.hoffman@icann.org> Thu, 18 April 2024 14:38 UTC

Return-Path: <paul.hoffman@icann.org>
X-Original-To: dd@ietfa.amsl.com
Delivered-To: dd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4984AC14F689; Thu, 18 Apr 2024 07:38:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jhbMP3P6SMzW; Thu, 18 Apr 2024 07:38:27 -0700 (PDT)
Received: from ppa2.lax.icann.org (ppa2.lax.icann.org [192.0.33.77]) (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 E653CC14F6ED; Thu, 18 Apr 2024 07:37:18 -0700 (PDT)
Received: from MBX112-W2-CO-1.pexch112.icann.org (out.mail.icann.org [64.78.33.5]) by ppa2.lax.icann.org (8.17.1.24/8.17.1.24) with ESMTPS id 43IEav4Y022527 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 18 Apr 2024 14:36:57 GMT
Received: from MBX112-W2-CO-1.pexch112.icann.org (10.226.41.128) by MBX112-W2-CO-2.pexch112.icann.org (10.226.41.130) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1258.28; Thu, 18 Apr 2024 07:36:56 -0700
Received: from MBX112-W2-CO-1.pexch112.icann.org ([169.254.44.235]) by MBX112-W2-CO-1.pexch112.icann.org ([169.254.44.235]) with mapi id 15.02.1258.028; Thu, 18 Apr 2024 07:36:56 -0700
From: Paul Hoffman <paul.hoffman@icann.org>
To: The IESG <iesg@ietf.org>
CC: Wes Hardaker <wjhns1@hardakers.net>, "dd@ietf.org" <dd@ietf.org>
Thread-Topic: Potential charter for a DNS Delegation Working Group
Thread-Index: AQHakZ3crjljmse8fUC7oAU4g5svaw==
Date: Thu, 18 Apr 2024 14:36:56 +0000
Message-ID: <E7D4EDF6-45D2-4DCE-83FE-50E9D92D5343@icann.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [192.0.32.234]
x-source-routing-agent: True
Content-Type: text/plain; charset="us-ascii"
Content-ID: <D4F5406BB59F9E46B5F0620CA20FE932@pexch112.icann.org>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.272,Aquarius:18.0.1011,Hydra:6.0.619,FMLib:17.11.176.26 definitions=2024-04-18_12,2024-04-17_01,2023-05-22_02
Archived-At: <https://mailarchive.ietf.org/arch/msg/dd/DZ1YOkS-LhVzBAmIir84ETO0veM>
Subject: [dd] Potential charter for a DNS Delegation Working Group
X-BeenThere: dd@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: DNS Delegation <dd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dd>, <mailto:dd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dd/>
List-Post: <mailto:dd@ietf.org>
List-Help: <mailto:dd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dd>, <mailto:dd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Apr 2024 14:38:33 -0000

Greetings, IESG. The DELEG BoF has completed its initial work and has a charter proposal for which there is strong consensus. There are plenty of people interested in the work, and we believe that an eventual working group will have enough energy to complete its work items. You can see the charter discussion on dd@ietf.org.

Please consider creating a WG from this charter, or something close to it. Note that BOF participants did express a strong desire for good coordination between the eventual working group and the DNSOP WG. This coordination should be worked out later by the sets of chairs, and (obviously) conflict avoidance for the two meetings will be needed.

--Paul Hoffman and Wes Hardaker, BoF co-chairs



# Background and Problem Space

The DNS protocol has traditionally had limited ability to signal to recursive resolvers about the capabilities of authoritative servers they communicate with.
In part, this stems from the inability of parents (often registries) to specify additional information about child delegations (often registrants) beyond NS, DS, and glue records.
Further complicating matters is the inability of a registrant to signal that the operation of a delegation point is being outsourced to a different operator, leaving a challenge when operators need to update parental information that is only in the control of the child.
Children often have more up-to-date information about the nameservers and DNSSEC keying information than their parents due to slowness, or complete lack, of automated child-to-parent updates. Data is often out of synchronization between parents and children which causes significant problems.

# Objective and Scope

To address these challenges, the working group will first develop the requirements for adding a new signaling mechanism that allows parents to return additional DNS delegation information about their children.

The working group will also list the other types of information not available today that might be provided over a designed signaling mechanism.

The potential first use cases for the working group will be new DNS authoritative signaling mechanisms for alternative DNS transports,
and delegation aliasing (where the parent returns a pointer to the service provider that will then return the needed delegation information).
The working group should also consider how well different solutions can be deployed, and should study possible negative consequences of deploying alternative delegation mechanisms.

The working group will then define the semantics of a new signaling mechanism, taking future extensibility into account.

The working group will specify extensions to the DNS, EPP, and other protocols that relate to delegation.
The working group will coordinate with other working groups as appropriate.

# Deliverables

- A document listing the requirements for a new signaling mechanism allowing parents to return additional information when communicating about a delegated child.
This is expected to be published as an informational RFC.

- A specification defining the new delegation information distribution mechanism. The WG will carry out an operational impact assessment and include corresponding operational and deployment considerations sections in the specification.
The specification will include a concept of operations that describes how both current and future systems will interact in an Internet-wide interoperable way.
This is expected to be published as a standards-track RFC.

- A specification for how to use the new delegation information to perform aliasing of delegation information.
This is expected to be published as a standards-track RFC.

- A specification for facilitating the use of additional transports for DNS.
This is expected to be published as a standards-track RFC.