DNS Delegation (deleg) Internet Drafts


      
 Problem Statement and Requirements for an Improved DNS Delegation Mechanism abbrev: DNS DELEG Requirements
 
 draft-ietf-deleg-requirements-00.txt
 Date: 30/08/2024
 Authors: tale, Edward Lewis, Jim Reid, Tim Wicinski
 Working Group: DNS Delegation (deleg)
Authoritative control of parts of the Domain Name System namespace are indicated with a special record type, the NS record, that can only indicate the name of the server which a client resolver should contact for more information. Any other features of that server must then be discovered through other mechanisms. This draft considers the limitations of the current system, benefits that could be gained by changing it, and what requirements constrain an updated design.


data-group-menu-data-url="/group/groupmenu.json">

Skip to main content

DNS Delegation (deleg)

WG Name DNS Delegation
Acronym deleg
Area Internet Area (int)
State Active
Charter charter-ietf-deleg-01 Approved
Document dependencies
Personnel Chairs Brian Haberman, Duane Wessels
Area Director Warren "Ace" Kumari
Secretary Tommy Jensen
Delegate Tommy Jensen
Mailing list Address dd@ietf.org
To subscribe https://www.ietf.org/mailman/listinfo/dd
Archive https://mailarchive.ietf.org/arch/browse/dd/
Chat Room address https://zulip.ietf.org/#narrow/stream/deleg

Charter for Working Group

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

Date Milestone Associated documents
Dec 2025 A specification for facilitating the use of additional transports for DNS.
Jun 2025 A specification for how to use the new delegation information to perform aliasing of delegation information.
Feb 2025 A specification defining the new delegation information distribution mechanism.
Dec 2024 A document listing the requirements for a new signaling mechanism allowing parents to return additional information when communicating about a delegated child.