WG Action: Formed DNS Delegation (deleg)

The IESG <iesg-secretary@ietf.org> Wed, 26 June 2024 16:43 UTC

Return-Path: <iesg-secretary@ietf.org>
X-Original-To: ietf-announce@ietf.org
Delivered-To: ietf-announce@ietfa.amsl.com
Received: from [10.244.2.35] (unknown [104.131.183.230]) by ietfa.amsl.com (Postfix) with ESMTP id 8DE0EC15108D; Wed, 26 Jun 2024 09:43:19 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Subject: WG Action: Formed DNS Delegation (deleg)
X-Test-IDTracker: no
X-IETF-IDTracker: 12.16.1
Auto-Submitted: auto-generated
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Message-ID: <171942019922.389482.12905494501523767569@dt-datatracker-5864469bc9-n5hqk>
Date: Wed, 26 Jun 2024 09:43:19 -0700
Message-ID-Hash: SBYU4ON2NTQ6B5WULPAPUOQAQ5MHYCNX
X-Message-ID-Hash: SBYU4ON2NTQ6B5WULPAPUOQAQ5MHYCNX
X-MailFrom: iesg-secretary@ietf.org
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-ietf-announce.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: The IESG <iesg@ietf.org>, dd@ietf.org, deleg-chairs@ietf.org
X-Mailman-Version: 3.3.9rc4
List-Id: "IETF announcement list. No discussions." <ietf-announce.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-announce/gVcSU6-PCujcfquFgvBUFL14Vqc>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf-announce>
List-Help: <mailto:ietf-announce-request@ietf.org?subject=help>
List-Owner: <mailto:ietf-announce-owner@ietf.org>
List-Post: <mailto:ietf-announce@ietf.org>
List-Subscribe: <mailto:ietf-announce-join@ietf.org>
List-Unsubscribe: <mailto:ietf-announce-leave@ietf.org>

A new IETF WG has been formed in the Internet Area. For additional
information, please contact the Area Directors or the WG Chairs.

DNS Delegation (deleg)
-----------------------------------------------------------------------
Current status: Proposed WG

Chairs:
  Brian Haberman <brian@innovationslab.net>
  Duane Wessels <dwessels@verisign.com>

Secretaries:
  Tommy Jensen <tojens@microsoft.com>

Assigned Area Director:
  Warren Kumari <warren@kumari.net>

Internet Area Directors:
  Erik Kline <ek.ietf@gmail.com>
  Éric Vyncke <evyncke@cisco.com>

Mailing list:
  Address: dd@ietf.org
  To subscribe: https://www.ietf.org/mailman/listinfo/dd
  Archive: https://mailarchive.ietf.org/arch/browse/dd/

Group page: https://datatracker.ietf.org/group/deleg/

Charter: https://datatracker.ietf.org/doc/charter-ietf-deleg/

# Background and Problem Space

The DNS protocol has limited ability for authoritative servers to signal
their capabilities to recursive resolvers. In part, this stems from the lack
of a mechanism for parents (often registries) to specify additional
information about child delegations (often registrants) beyond NS, DS, and
glue records. Further complicating matters is the similar lack of a mechanism
for 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. Data
is often out of synchronization between parents and children, which causes
significant operational problems.

# Objective and Scope

To address these challenges, the DELEG working group will first document the
requirements for adding a new DNS signaling mechanism that allows parents to
return additional DNS delegation information about their children. This
includes the requirement for the new mechanism to interoperate with the
existing DNS and to not break DNS resolvers and clients that are not aware of
it. In addition, this document could also list the other types of information
not available today that might be provided over a designed signaling
mechanism.

The 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 consequences of deploying alternative delegation mechanisms.

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

The working group will specify extensions to the DNS.

The initial version of the requirements document should have broad general
consensus and must be adopted by the WG before work on the solution documents
begins.

- The WG will coordinate closely with other WGs, including DNSOP, ADD, and
other working groups and directorates as appropriate. This is especially true
for WG adoption and Last Calls.

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

Milestones:

  Dec 2024 - A document listing the requirements for a new signaling
  mechanism allowing parents to return additional information when
  communicating about a delegated child.

  Feb 2025 - A specification defining the new delegation information
  distribution mechanism.

  Jun 2025 - A specification for how to use the new delegation information to
  perform aliasing of delegation information.

  Dec 2025 - A specification for facilitating the use of additional
  transports for DNS.