Domain Control Validation for DNS Delegations
draft-nygren-dnsop-domain-delegation-validation-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Erik Nygren , Peter Thomassen , Shumon Huque | ||
| Last updated | 2026-07-06 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-nygren-dnsop-domain-delegation-validation-00
Domain Name System Operations E. Nygren
Internet-Draft Akamai Technologies
Intended status: Informational P. Thomassen
Expires: 7 January 2027 deSEC
S. Huque
Salesforce
6 July 2026
Domain Control Validation for DNS Delegations
draft-nygren-dnsop-domain-delegation-validation-00
Abstract
The techniques specified in
[I-D.draft-ietf-dnsop-domain-verification-techniques] for using the
DNS to verify ownership or control of a domain in the Domain Name
System (DNS) rely on the domain already being properly delegated to a
DNS authority. For the specific case where the Application Service
Provider is providing authoritative DNS services, the existing
approaches don't provide a way to bootstrap domain validation onto a
new Authoritative DNS Application Service provider.
This specification proposes a mechanism for "Domain Control
Validation" for cases where the User and DNS Administrator are
validating control over a domain to an Authoritative DNS Application
Service Provider and thus do not have the ability to add records
within the domain. In this case, validation must be performed by the
User taking actions in the DNS Registrar or Parent Zone that
demonstrate control over the domain, such as by adding DNS NS records
as validation records.
About This Document
This note is to be removed before publishing as an RFC.
The latest revision of this draft can be found at
https://enygren.github.io/draft-nygren-dnsop-domain-delegation-
validation/draft-nygren-dnsop-domain-delegation-validation.html.
Status information for this document may be found at
https://datatracker.ietf.org/doc/draft-nygren-dnsop-domain-
delegation-validation/.
Discussion of this document takes place on the Domain Name System
Operations Working Group mailing list (mailto:dnsop@ietf.org), which
is archived at https://mailarchive.ietf.org/arch/browse/dnsop/.
Subscribe at https://www.ietf.org/mailman/listinfo/dnsop/.
Nygren, et al. Expires 7 January 2027 [Page 1]
Internet-Draft Domain Control Validation for DNS Delega July 2026
Source for this draft and an issue tracker can be found at
https://github.com/enygren/draft-nygren-dnsop-domain-delegation-
validation.
Status of This Memo
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 7 January 2027.
Copyright Notice
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 4
3. Purpose of Domain Control Validation for Delegation . . . . . 4
4. Threat Model . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 6
5.1. NS Record based Validation . . . . . . . . . . . . . . . 6
5.1.1. Authoritative name servers for NS validation
records . . . . . . . . . . . . . . . . . . . . . . . 7
5.2. DELEG SvcParam based Validation (future) . . . . . . . . 8
5.3. Removal and Cleanup . . . . . . . . . . . . . . . . . . . 8
6. Supporting Multiple Authoritative DNS Providers . . . . . . . 8
Nygren, et al. Expires 7 January 2027 [Page 2]
Internet-Draft Domain Control Validation for DNS Delega July 2026
7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7.1. DNS Spoofing and DNSSEC Validation . . . . . . . . . . . 8
8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 9
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
10.1. Normative References . . . . . . . . . . . . . . . . . . 9
10.2. Informative References . . . . . . . . . . . . . . . . . 9
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction
Application Service Providers providing Authoritative DNS services
need a way for domain owners (Users) to prove that they control a
particular DNS domain before the Application Service Provider can
allow them to provision the authoritative domain, thus granting a DNS
Administrator access to modify the domain.
Security researchers have called out (see [SITTING-DUCKS]) that there
is active exploitation of "lame delegations" ([RFC9499]) where domain
registrations remain active and delegate to an Authoritative DNS
Application Service Provider, but where the User account at that
Application Service Provider has lapsed or where they have "deleted"
the domain but not removed the delegation. Without validation, an
attacker may be able to provision that domain at the Application
Service Provider and gain control over it. For new domains there is
also a potential race condition during registration where the domain
owner who registers (and delegates) a domain could be beat out by an
attacker in provisioning the domain in the Authoritative DNS
Application Service Provider.
While DNS TXT record validation as specified in
[I-D.draft-ietf-dnsop-domain-verification-techniques] works for
existing domains that the domain's DNS Administrator can add records
to (such as for transferring to a different Authoritative DNS
Application Service Provider), this does not work for domains that
are newly provisioned or where the User and DNS Administrator are
trying to re-establish control over.
For these cases, using DNS to demonstrate control over the domain
must be performed through adding or modifying parent-side zone
records, such as DNS NS records ([RFC1035]).
This specification is also useful for performing validation during
account recovery cases at Authoritative DNS Application Service
Providers, where a User needs to validate that they have the control
needed for a 2FA or password reset for a domain.
Nygren, et al. Expires 7 January 2027 [Page 3]
Internet-Draft Domain Control Validation for DNS Delega July 2026
While non-DNS mechanisms are possible, such as using EPP authInfo
([RFC5731]) or having the DNS Registrar add attributes to RDAP
([RFC9083]), those are not described in this specification.
2. Conventions and Definitions
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 specification uses the following terms defined in
[I-D.draft-ietf-dnsop-domain-verification-techniques]: Application
Service Provider, DNS Administrator, Intermediary, User, Unique
Token, and Validation Record.
This specification uses the following terms defined in [RFC9499] for
general DNS Terminology: Registrar, Registrant, Registry,
Superordinate/Parent, Subordinate/Child, and Lame Delegation.
3. Purpose of Domain Control Validation for Delegation
Domain Control Validation for Delegation allows a User to demonstrate
to an Application Service Provider providing Authoritative DNS
services that the User's DNS Administrator should be given control
over a Child Zone corresponding to a domain.
Because this challenge becomes publicly visible as soon as it is
published into the DNS, the security properties rely on the causal
relationship between the Application Service Provider generating a
specific challenge and the challenge appearing in the DNS at a
specified location.
For Domain Control Validation for Delegation, the DNS challenge must
appear in a Parent Side record.
For the case where the domain is delegated from a delegation-centric
zone operated by a DNS Registry, this addition needs to demonstrate
that the User is also the DNS Registrant in control of the domain.
The causal relationship in this case is:
Application Service Provider for Authoritative DNS (challenge generation)
-> User / Registrant for Child/Subordinate Domain
-> Registrar
-> Registry
-> Parent/Superordinate DNS Zone update
-> Application Service Provider for Authoritative DNS (for validation)
Nygren, et al. Expires 7 January 2027 [Page 4]
Internet-Draft Domain Control Validation for DNS Delega July 2026
In the case where a domain is delegated from a parent that is not a
delegation-centric zone in a registry, the Parent Zone DNS
Administrator is making changes to demonstrate control over the zone,
with a causal relationship of:
Application Service Provider for Authoritative DNS (challenge generation)
-> User / Registrant for Child Domain
-> Parent Zone DNS Administrator
-> Parent DNS Zone update
-> Application Service Provider for Authoritative DNS (for validation)
4. Threat Model
The threat model here is an extension of that in
[I-D.draft-ietf-dnsop-domain-verification-techniques], however this
is the more narrow and specific case since the application
(Authoritative DNS service) is known.
The specific threats we are concerned with include:
* T1. An attacker is able to exploit a pre-existing lame delegation
to provision Authoritative DNS services at the target of the lame
delegation without approval from the domain owner.
* T2. An attacker is able to exploit a race condition in the DNS
registration and/or delegation process to gain control over the
zone for a domain at an Authoritative DNS Application Service
Provider. This might happen either before or after the domain has
been delegated, but prior to the actual owner of the domain
provisioning control.
* T3. An attacker might try to transfer a domain within an
Authoritative DNS Application Service Provider from the rightful
owner/operator's account to an account controlled by the attacker.
* T4. An attacker who can spoof DNS responses might be able to
defeat validation, absent DNSSEC validation.
Since information in the DNS is public, the attacker should be
assumed to have access to any validation records.
Threats NOT covered by this include:
* N1. Compromise of the Authoritative DNS Application Service
Provider or compromise of the User's account there. This could
also be used by an attacker to take over control of the domain.
Nygren, et al. Expires 7 January 2027 [Page 5]
Internet-Draft Domain Control Validation for DNS Delega July 2026
* N2. A User retaining control over a domain at a DNS Application
Service Provider when a new owner/Registrant for the domain
delegates it.
Note that covered threat T3 and not-covered threat N2 are in-tension.
When a domain transfers ownership at the parent without moving
between Authoritative DNS Application Service Providers, it should be
possible to transfer operational control to the new owner, but
extreme care must be taken to authorize this transfer.
As threats T1 and T2 are mitigated by one-off validation, there is no
need for validation records to persist.
5. Recommendations
Domain Control Validation during DNS delegation is implemented
through DNS NS Record based validation as described below.
5.1. NS Record based Validation
The RECOMMENDED method of doing DNS-based domain control validation
is to use a DNS NS record containing a Unique Token as the Validation
Record within one of the parent-side zone NS record delegations. The
Authoritative DNS Application Service Provider supplies an additional
DNS authority name to use that contains this Unique Token.
The Unique Token SHOULD be encoded with Base32 encoding ([RFC4648],
Section 6) or hexadecimal base16 encoding ([RFC4648], Section 8).
The QNAME is the domain being validated, and the RDATA MUST contain a
nameserver name that contains a Unique Token provided by the
Application Service Provider (constructed according to the properties
described in [I-D.draft-ietf-dnsop-domain-verification-techniques]).
For example, in the parent-side zone:
$domain IN NS ns1.example.com.
$domain IN NS ns2.example.com.
$domain IN NS ns-<unique-token>.authdnsdv.example.net.
To validate these, the Application Service Provider queries for the
parent-side NS records for the domain being validated.
Application Service Providers MUST validate that one of the parent-
side DNS NS records is the DNS authority name they provided to that
User for that specific domain and contains the matching Unique Token.
The Application Service Provider MUST allow other NS records to also
be present alongside the NS record being used for validation.
Nygren, et al. Expires 7 January 2027 [Page 6]
Internet-Draft Domain Control Validation for DNS Delega July 2026
Note that using a recursive resolver to perform the validation may
not be possible due to the need to distinguish child-side from
parent-side NS records.
The validation NS record MUST be included in-addition to (rather than
instead of) other NS records which will persist following the removal
of the validation NS record.
Token metadata is not readily possible with this approach.
5.1.1. Authoritative name servers for NS validation records
The Application Service Provider SHOULD provide the NS record
authoritative server name for validation from a different TLD (top-
level domain) from the domain being validated.
Because the validation authoritative server name would then be out-
of-bailiwick relative to the domain being validated, it would not
receive glue records in the parent zone's delegation response,
requiring resolvers to perform a separate address resolution before
it can be queried. This may make some resolver implementations less
likely to select it during ordinary server selection, compared to
already-glued in-bailiwick authorities, reducing (but not
eliminating) the likelihood of this validation-only NS record being
used for ongoing production query traffic.
The Application Service Provider MUST operate DNS service on IP
addresses returned by the A/AAAA records for the authoritative server
name, and those IPs must be treated as authoritative name servers for
the zone.
Note that Registrars often have restrictions preventing in-bailiwick
authorities from being referenced without first provisioning them,
which is another reason for using a name from an unrelated TLD.
For example, one setup for validating foo.example might include:
foo.example. IN NS ns1.dnsprovider.example.
foo.example. IN NS ns2.dnsprovider.example.
foo.example. IN NS ns-<unique-token>.authdnsdv.example.net.
ns1.dnsprovider.example. IN AAAA 2001:db8:1::1
IN A 203.0.113.1
ns2.dnsprovider.example. IN AAAA 2001:db8:2::2
IN A 192.0.2.5
*.authdnsdv.example.net. IN AAAA 2001:db8:1::5
IN A 203.0.113.1
Nygren, et al. Expires 7 January 2027 [Page 7]
Internet-Draft Domain Control Validation for DNS Delega July 2026
which allows the ns*.dnsprovider.example to be configured as
authorities to be returned in Additional records within the .example
domain.
If the example domain were to be within .net then authorities outside
of .net would want to be used for validation purposes.
5.2. DELEG SvcParam based Validation (future)
Once DELEG ([I-D.draft-ietf-deleg]) is widely deployed, another
option would be for a SvcParam to be registered for validation
purposes. This would be defined in a future specification but would
include the validation Unique Token along with the delegation:
foo.example. DELEG include-delegparam=config2.example.net. validation=<unique-token>
5.3. Removal and Cleanup
After validation is performed, the User SHOULD remove the validation
record from the parent zone.
6. Supporting Multiple Authoritative DNS Providers
Nothing in this specification prevents a zone from having multiple
Authoritative DNS Providers, as the NS records may simultaneous
include authoritative name servers from the multiple providers
(possibly including ones used for validation).
7. Security Considerations
Many of the Security Considerations are shared with
[I-D.draft-ietf-dnsop-domain-verification-techniques] and are not
repeated here. Additional considerations follow.
7.1. DNS Spoofing and DNSSEC Validation
The parent side zone SHOULD be signed using DNSSEC [RFC9364] to
protect Validation Records against DNS spoofing attacks, including
from on-path attackers.
Application Service Providers MUST use a trusted DNSSEC validating
resolver to verify Validation Records they have requested to be
deployed.
Application Service Providers MUST confirm that the NS validation
records are present in the parent-side zone.
Nygren, et al. Expires 7 January 2027 [Page 8]
Internet-Draft Domain Control Validation for DNS Delega July 2026
8. Privacy Considerations
TODO - consider if any exist.
9. IANA Considerations
This document has no IANA actions.
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<https://www.rfc-editor.org/rfc/rfc4648>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
10.2. Informative References
[I-D.draft-ietf-deleg]
Špaček, P., Weber, R., and Lawrence, "Extensible
Delegation for DNS", Work in Progress, Internet-Draft,
draft-ietf-deleg-10, 4 July 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-deleg-
10>.
[I-D.draft-ietf-dnsop-domain-verification-techniques]
Sahib, S. K., Huque, S., Wouters, P., Nygren, E., and T.
Wicinski, "Domain Control Validation using DNS", Work in
Progress, Internet-Draft, draft-ietf-dnsop-domain-
verification-techniques-13, 21 June 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-
domain-verification-techniques-13>.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <https://www.rfc-editor.org/rfc/rfc1035>.
Nygren, et al. Expires 7 January 2027 [Page 9]
Internet-Draft Domain Control Validation for DNS Delega July 2026
[RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)
Domain Name Mapping", STD 69, RFC 5731,
DOI 10.17487/RFC5731, August 2009,
<https://www.rfc-editor.org/rfc/rfc5731>.
[RFC9083] Hollenbeck, S. and A. Newton, "JSON Responses for the
Registration Data Access Protocol (RDAP)", STD 95,
RFC 9083, DOI 10.17487/RFC9083, June 2021,
<https://www.rfc-editor.org/rfc/rfc9083>.
[RFC9364] Hoffman, P., "DNS Security Extensions (DNSSEC)", BCP 237,
RFC 9364, DOI 10.17487/RFC9364, February 2023,
<https://www.rfc-editor.org/rfc/rfc9364>.
[RFC9499] Hoffman, P. and K. Fujiwara, "DNS Terminology", BCP 219,
RFC 9499, DOI 10.17487/RFC9499, March 2024,
<https://www.rfc-editor.org/rfc/rfc9499>.
[SITTING-DUCKS]
Krebs, B., "Don’t Let Your Domain Name Become a Sitting
Duck", n.d., <https://krebsonsecurity.com/2024/07/dont-
let-your-domain-name-become-a-sitting-duck/>.
[SUBDOMAIN-TAKEOVER]
Mozilla, "Subdomain takeovers", n.d.,
<https://developer.mozilla.org/en-US/docs/Web/Security/
Subdomain_takeovers>.
Appendix A. Acknowledgments
Thank you to Peter Thomassen, ..., (add names here) for their
feedback and suggestions on this document.
Authors' Addresses
Erik Nygren
Akamai Technologies
Email: erik+ietf@nygren.org
Peter Thomassen
deSEC
Email: peter@desec.io
Shumon Huque
Salesforce
Email: shuque@gmail.com
Nygren, et al. Expires 7 January 2027 [Page 10]