| Internet-Draft | DELEG secure transports | May 2026 |
| Hoffman & Weber | Expires 27 November 2026 | [Page] |
The DELEG base protocol allows a DNS zone operator to specify servers to be used when delegating zones to other DNS nameservers. This document extends the base protocol to allow zone operators to specify secure transports for those delegations.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 27 November 2026.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
In the DELEG base protocol ([I-D.ietf-deleg]), a DNS zone operator uses the DELEG resource record to delegate zones to other DNS nameservers. In the base protocol, that delegation is always assumed to be using classical DNS on port 53. Some operators want to use secure transports for their name service, and want DELEG-aware resolvers to use those transports for name resolution. This document defines extensions to the DELEG record to allow such specification.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
This document defines new DelegInfo DelegInfoKey values: secure-transport, no-do53, and tlsa.
The DelegInfoValue for secure-transport is an unordered collection of names of transports.
There is no DelegInfoValue for no-do53.
The DelegInfoValue for tlsa-desc is a string reprinting an TLSA record.¶
The secure-transport DelegInfoKey lists the secure transports that are supported for a particular delegation target.
It MUST only appear in a DelegInfos with a server-ipv4, server-ipv6 orserver-name DelegInfoKey.
(This restriction might change if future specifications add new types of delegation targets.)¶
A DELEG-enabled resolver MAY use one or more of the listed values to choose a secure transport for its communications with the given delegation target.
If no secure-transport key is given, the DELEG-aware resolver MUST use classical DNS over port 53 (Do53).¶
The values for the elements of the DelegInfoValue for the secure-transport DelegInfoKey are adot and adoq.
Additional values may be defined in the future; see Section 4.2 for rules on how such values might be defined.¶
adot indicates that the delegation target from the server-ipv4, server-ipv6, or server-name DelegInfoKey
supports DNS over TLS (DoT) [RFC7858].¶
adoq indicates that the delegation target from the server-ipv4, server-ipv6, or server-name DelegInfoKey
supports DNS over QUIC (DoQ) [RFC9250].¶
Note that DNS over HTTPS (DoH) [RFC8484] is not supported by this document. This is because DoH adds no security over DoT, while adding complexity to both the client (the recursive resolver) and the server (the authoritative server). In addition, using DoH requires knowing the URI template, which would further complicate the DELEG RRset.¶
The no-do53 DelegInfoKey indicates that the delegation target does not support Do53; it supports only secure transports.
The no-do53 DelegInfoKey, which takes no value, MUST only appear in a DelegInfos with a secure-transport DelegInfoKey.¶
The tlsa DelegInfoKey indicates certificate authority (CA) and public key information that a DELEG-aware resolver MAY use for authenticating a DoT or DoQ connection.
The value is a string that is a TLSA ([RFC6698]) Rdata in presentation format.
It MUST only appear in a DelegInfos with a secure-transport key.¶
At the time that this document is written, ADoT and ADoQ servers use a variety of issuers for their TLS certificates:
self-issued (often mistakenly called "self-signed"), a bespoke CA created for ADoT, and Web PKI issuers.
All of these can be indicated in a tlsa value.¶
If there is no tlsa key, the resolver is free to choose any authentication mechanism, including accepting any certificate.¶
; A delegation target (IPv4 address) that is expected to respond ; with ADoT and Do53 example. DELEG server-ipv4=192.0.2.1 secure-transport=adot ; A delegation target (server name) that is expected to respond ; with ADoT, ADoQ, and Do53 example. DELEG server-name=ns1.xd secure-transport=adot,adoq ; A delegation target (IPv4 address) that is expected to respond ; with ADoT but *not* over Do53 example. DELEG server-ipv4=192.0.2.1 secure-transport=adot no-do53 ; A delegation with a tlsa key example. DELEG server-name=ns1.xd secure-transport=adot ( tlsa="0 0 1 d2abde240d7cd3ee6b4b28c54df034b9 7983a1d16e8a410e4561cb106618e971" }¶
IANA is requested to add the following values to the "DELEG Delegation Information" registry as described in [I-D.ietf-deleg].¶
Number: 5 Name: secure-transport Meaning: An unordered collection of names of transports Reference: This document Change Controller: IETF Number: 6 Name: no-do53 Meaning: Indicates an authoritative server does not support Do53 Reference: This document Change Controller: IETF Number: 6 Name: tlsa Meaning: A TLSA Rdata associated with a secure transport Reference: This document Change Controller: IETF¶
IANA is requested to create the "secure-transport DelegInfoKey values" registry. This is to be a sub-registry under the "DELEG Delegation Information" registry.¶
A registration MUST include the following fields:¶
Name: Unique presentation name Meaning: A short description Reference: Location of specification or registration source Change Controller: Person or entity, with contact information if appropriate¶
To enable code reuse from SVCB parsers, the requirements for registered Name exactly copy requirements set by [RFC9460] section 14.3.1: The characters in the registered Name field entry MUST be lowercase alphanumeric or "-".¶
The registration policy for new entries is Expert Review ([RFC8126]). The designated expert MUST ensure that the reference is stable. The reference MAY be any individual's Internet-Draft or a document from any other source with similar assurances of stability and availability.¶
Initial values for this registry are:¶
Name: adot Meaning: Supports ADoT Reference: This document Change Controller: IETF Name: adoq Meaning: Supports ADoQ Reference: This document Change Controller: IETF¶
Although this document defines an authentication mechanism Section 2.3, it does not require that DoT or DoQ sessions be authenticated. Of course, this reduces the normal level of TLS and QUIC security from "fully authenticated" to "not authenticated at all".¶
Many people in the DELEG Working Group contributed early suggestions for this document.¶