Domain Control Validation for DNS Delegations

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

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

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)

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

• 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.¶

   $domain  IN NS   ns1.example.com.
   $domain  IN NS   ns2.example.com.
   $domain  IN NS   ns-<unique-token>.authdnsdv.example.net.

   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

foo.example.  DELEG include-delegparam=config2.example.net. validation=<unique-token>

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

8. Privacy Considerations

TODO - consider if any exist.¶

9. IANA Considerations

This document has no IANA actions.¶

10. References

Appendix A. Acknowledgments

Thank you to Peter Thomassen, ..., (add names here) for their feedback and suggestions on this document.¶

Authors' Addresses