Operational Guidance for Authoritative DNS Operator Changes with Service Endpoint Migration for Registered Domain Names
draft-feng-dnsop-authdns-operator-change-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 | Yuming Feng , Yu Zhang , Di Ma , Weizhe Zhang , Rongwei Yang | ||
| Last updated | 2026-08-10 | ||
| 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-feng-dnsop-authdns-operator-change-00
DNSOP Working Group Y. Feng
Internet-Draft Pengcheng Laboratory
Intended status: Informational Y. Zhang
Expires: 11 February 2027 Harbin Institute of Technology
D. Ma
ZDNS
W. Zhang
Harbin Institute of Technology
R. Yang
Pengcheng Laboratory
10 August 2026
Operational Guidance for Authoritative DNS Operator Changes with Service
Endpoint Migration for Registered Domain Names
draft-feng-dnsop-authdns-operator-change-00
Abstract
A registered domain name can change its authoritative DNS operator
while the registrant also migrates service endpoints, such as web,
API, CDN, mail, or cloud-hosted services. In this situation, service
RRsets such as A, AAAA, CNAME, MX, SRV, SVCB, and HTTPS RRsets can
change at the same time as the parent-side delegation changes.
The parent-side delegation change is not observed by all recursive
resolvers at the same instant. During the transition, some resolvers
can continue to query the losing DNS operator while others query the
gaining DNS operator. If the losing operator continues to serve
stale service RRsets, or if it stops serving the zone too early,
users can receive different answers depending on resolver cache state
and can experience intermittent service failure.
This document provides operational guidance for authoritative DNS
operator changes with service endpoint migration for registered
domain names. It recommends a registrant-authorized change plan, a
consistency profile for in-scope service RRsets, synchronized
provisioning or a common source of truth, a hold period during which
the losing DNS operator continues to serve target or otherwise
equivalent data, and verification points that directly compare the
losing and gaining authoritative servers and classify observed states
as planned, service-risk, or unexpected-delegation conditions.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Feng, et al. Expires 11 February 2027 [Page 1]
Internet-Draft DNS Operator Endpoint Migration August 2026
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 11 February 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. Scope and Relation to Existing Work . . . . . . . . . . . . . 4
3. Conventions and Terminology . . . . . . . . . . . . . . . . . 5
3.1. Requirements Language . . . . . . . . . . . . . . . . . . 6
3.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 8
5. Operational Model . . . . . . . . . . . . . . . . . . . . . . 10
6. Operational Requirements . . . . . . . . . . . . . . . . . . 12
6.1. Change Plan, Roles, and Authorization . . . . . . . . . . 12
6.2. Consistency Profile and Service RRset Cutover . . . . . . 13
6.3. Synchronization and Change Control . . . . . . . . . . . 14
6.4. Parent-Side Delegation Change . . . . . . . . . . . . . . 15
6.5. Service Continuity and Hold Period . . . . . . . . . . . 15
6.6. DNSSEC . . . . . . . . . . . . . . . . . . . . . . . . . 16
6.7. Policy-Based Answers . . . . . . . . . . . . . . . . . . 16
6.8. Verification and Risk Classification . . . . . . . . . . 17
7. Using Consistency Evidence for Risk Classification . . . . . 17
8. Example Timeline . . . . . . . . . . . . . . . . . . . . . . 19
9. Operational Considerations . . . . . . . . . . . . . . . . . 20
10. Security Considerations . . . . . . . . . . . . . . . . . . . 21
Feng, et al. Expires 11 February 2027 [Page 2]
Internet-Draft DNS Operator Endpoint Migration August 2026
11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 22
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
13. Normative References . . . . . . . . . . . . . . . . . . . . 22
14. Informative References . . . . . . . . . . . . . . . . . . . 22
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
1. Introduction
The authoritative DNS service for a registered domain name is
sometimes moved from one DNS operator to another while the registrant
also migrates service endpoints. For example, an enterprise might
move web hosting, CDN service, API endpoints, mail service, or cloud
infrastructure from one provider or environment to another and change
authoritative DNS operators as part of the same maintenance window.
In this scenario, the DNS change is not only a parent-side NS RRset
change. The service RRsets used by applications can also change.
For example, A or AAAA records can point to new addresses, CNAME
records can point to a new CDN or platform target, MX records can
point to a new mail service, and SVCB or HTTPS records can express
new service endpoints. Those service RRsets are the data that users
and applications ultimately depend on.
Established DNS hosting migration practices commonly copy and verify
the existing zone data at the gaining DNS operator, change the
parent-side name servers, monitor service, and retain the hosted zone
at the losing DNS operator for a period. They also commonly avoid
changing service endpoint RRsets until the delegation transition has
settled. When service RRsets and their corresponding endpoints
remain available and unchanged during the delegation transition, this
is a low-risk special case of the operational model in this document.
This document does not replace or redefine those practices. It
focuses on the part that has not been made sufficiently explicit for
migrations in which the authoritative DNS operator change overlaps
with a service endpoint migration. As long as cached delegation
information can cause either authoritative path to be queried, the
losing and gaining DNS operators need to serve target or otherwise
equivalent in-scope service data. The contribution of this document
is to define the consistency profile, hold period, direct
authoritative comparison, verifiable exit criteria, and risk
classification for that overlapping interval.
This data consistency also has security value. A parent-side
delegation change without an authorized plan, or a material
difference between the old and new authoritative paths, can be used
as evidence for risk classification. The evidence does not prove
Feng, et al. Expires 11 February 2027 [Page 3]
Internet-Draft DNS Operator Endpoint Migration August 2026
whether a change is authorized, but it can help verification points
distinguish a planned migration from operational failure or a
possible unauthorized delegation change.
2. Scope and Relation to Existing Work
This document assumes the DNS concepts and protocol behavior defined
in [RFC1034] and [RFC1035]. It provides DNS operational guidance.
It does not define a new DNS RR type, a new wire protocol, a new EPP
extension, or new resolver behavior.
The scope of this document is limited to planned authoritative DNS
operator changes for registered domain names, such as "example.com"
or "example.com.cn", where the operator change is coordinated with a
service endpoint migration. The service endpoint migration causes
one or more in-scope service RRsets to change from pre-cutover data
to target data.
Ordinary DNS hosting migrations in which service RRsets and their
corresponding service endpoints remain unchanged throughout the
delegation transition are out of scope. Established DNS hosting
migration practices remain appropriate for those cases. This
document applies when a service endpoint migration is part of the
same change plan and the service RRset cutover either overlaps with
the period in which the losing authoritative path can still be
queried or is deferred until explicit exit criteria are met.
This document is not about registrar transfer as such. A registrar
can be involved because it may be the party through which the
registrant requests parent-side NS, glue, or DS changes. A registrar
can also be the DNS operator for a domain name, or the registrar and
DNS operator can be different entities. The subject of this document
is the authoritative DNS operator change and the consistency of
service RRsets served by the losing and gaining authoritative DNS
operators.
This document does not specify operational requirements for the root
zone, for TLD registry operation, or for changes in the relationship
between a TLD registry and the root zone.
The terminology in this document follows the DNS registration model
and zone terminology in [RFC9499]. In particular, this document uses
"registrant", "registrar", "registry", "DNS operator", "parent",
"child", "zone cut", and "delegation" in the sense used by that
document.
Several existing documents cover adjacent parts of the problem:
Feng, et al. Expires 11 February 2027 [Page 4]
Internet-Draft DNS Operator Endpoint Migration August 2026
* [RFC2308] describes DNS negative caching, which can affect
migration timing when resolvers cache NXDOMAIN or NODATA
responses.
* [RFC4033], [RFC4034], [RFC4035], [RFC5155], and [RFC6781] describe
DNSSEC protocol and operational practices, including authenticated
denial of existence and changes between cooperating and non-
cooperating DNS operators.
* [RFC8901] describes multi-signer DNSSEC models for zones served by
multiple DNS providers.
* [RFC7344], [RFC8078], and [RFC7477] describe in-band signaling for
child-to-parent updates of DS, DNSKEY, NS, and glue-related data.
* [RFC1995], [RFC5936], and [RFC2845] describe DNS zone transfer and
transaction authentication mechanisms that can be used in some
synchronization arrangements.
* [RFC5731] describes EPP domain name mapping used by many registrar
and registry systems for domain provisioning.
Authoritative DNS provider guidance commonly recommends lowering
TTLs, copying existing records to the gaining provider, comparing old
and new hosted zones, updating the parent-side name servers,
monitoring service, and delaying deletion of the old zone. For
example, AWS Route 53 migration guidance recommends copying and
comparing records and warns not to delete the old hosted zone for at
least 48 hours after updating the domain registration to use the new
name servers [AWS-ROUTE53-MIGRATION]. Those practices form the
operational baseline for this document and are not replaced by it.
This document complements those standards and operational practices.
The additional gap addressed here is that, when service endpoints are
migrated during the operator change, the hold period, consistency,
direct comparison, and exit criteria need to be explicit. Deferring
the service RRset cutover until the losing authoritative path is no
longer operationally relevant is a low-risk special case when it is
feasible and when the decision to proceed is verified. When
operational constraints cause service RRsets to change while the
losing authoritative path can still receive queries, the losing DNS
operator also needs to serve the target service RRsets, or otherwise
equivalent answers, during the agreed hold period.
3. Conventions and Terminology
Feng, et al. Expires 11 February 2027 [Page 5]
Internet-Draft DNS Operator Endpoint Migration August 2026
3.1. Requirements Language
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 is informational. The requirements language is used to
state operational requirements for parties that choose to implement
or claim conformance to the practices described here.
3.2. Terminology
Registered domain name
In this document, a domain name registered by a registrant through
a registry/registrar or equivalent registration mechanism and
delegated in the parent zone. This term is used to limit the
scope of this document; it does not define a new DNS protocol
concept.
Authoritative DNS operator
A DNS operator, as defined by [RFC9499], that runs authoritative
servers for the registered domain name in scope.
Losing DNS operator
The authoritative DNS operator that serves the zone for the
registered domain name before the operator change. This follows
the terminology used in [RFC6781].
Gaining DNS operator
The authoritative DNS operator that is intended to serve the zone
for the registered domain name after the operator change. This
follows the terminology used in [RFC6781].
Operator change
A planned movement of authoritative DNS service for a registered
domain name from a losing DNS operator to a gaining DNS operator.
The movement normally involves a parent-side delegation change.
Service endpoint migration
A planned movement of one or more application or infrastructure
endpoints used by the registered domain name, such as web, API,
CDN, mail, or cloud-hosted endpoints, from pre-cutover endpoints
to target endpoints.
Feng, et al. Expires 11 February 2027 [Page 6]
Internet-Draft DNS Operator Endpoint Migration August 2026
In-scope service RRset
An RRset covered by the consistency profile because it materially
affects the service endpoint migration or its validation.
Examples include address, alias, mail, service-binding, and
service-validation RRsets such as A, AAAA, CNAME, MX, SRV, SVCB,
HTTPS, and service-related TXT RRsets when they are material to
the migration; CNAME-chain targets needed to establish service
meaning; relevant negative answers; and DNSSEC validation state.
Service RRset cutover
The planned change from pre-cutover in-scope service RRsets to
target in-scope service RRsets. This can occur before, during, or
after the parent-side delegation change, but it needs to be
coordinated across both authoritative DNS operators during the
transition and the hold period.
Change plan
The registrant-authorized record of the intended operator change
and service endpoint migration, including scope, parties, timing,
source of truth, synchronization or provisioning arrangement,
parent-side changes, service RRset cutover, DNSSEC handling,
validation method, hold period, and rollback conditions.
Consistency profile
The set of names, RR types, DNSSEC states, dynamic-answer
conditions, service RRset cutover rules, and comparison rules used
to determine whether the losing and gaining DNS operators are
serving equivalent in-scope service RRsets.
Equivalent answer
A DNS answer that is equivalent for operational purposes under the
consistency profile. Equivalence does not require identical wire
messages or RR ordering. It generally does require compatible
RCODEs, relevant RRsets, DNSSEC validity, negative-response proofs
when relevant, and service meaning.
Hold period
The period after the parent-side delegation change during which
the losing DNS operator continues to serve correct authoritative
answers for the registered domain name under the consistency
profile.
Verification point
A system that observes the parent delegation, directly queries the
losing and gaining DNS operators, compares responses under the
consistency profile, and records classifications. A verification
point can be run by the registrant, a DNS operator, a resolver
operator, a registry or registrar, or a monitoring service.
Feng, et al. Expires 11 February 2027 [Page 7]
Internet-Draft DNS Operator Endpoint Migration August 2026
4. Problem Statement
This document addresses a specific operational scenario: a registered
domain name changes authoritative DNS operators while service
endpoints also migrate. The migration can change user-visible
service RRsets, such as A, AAAA, CNAME, MX, SRV, SVCB, HTTPS, or
service-related TXT RRsets. After the parent-side NS RRset is
changed, recursive resolvers do not all stop using the losing
authoritative path at the same time. Some can still query the losing
DNS operator while others query the gaining DNS operator.
Established best practices for DNS hosting migration commonly include
provisioning and verifying equivalent zone data at the gaining DNS
operator before the parent-side delegation is changed, retaining the
hosted zone at the losing DNS operator during cache convergence, and
avoiding changes to service endpoint RRsets until the delegation
transition has settled. These practices have important implicit
assumptions: both authoritative paths remain operationally equivalent
while they can be queried; the endpoints identified by their answers
remain available; the losing DNS operator continues to serve the
zone; and the service RRset cutover does not proceed until the losing
authoritative path is no longer operationally relevant. When those
assumptions hold, a migration following the established practices is
a low-risk special case of the model in this document.
The gap addressed by this document appears when those assumptions
need to be made explicit or do not hold. If only the gaining DNS
operator is updated to target data, the losing DNS operator can
continue to return pre-cutover addresses, CNAME targets, mail
exchangers, service bindings, or negative answers to resolvers that
still follow cached delegation information. Merely retaining the
hosted zone at the losing DNS operator is therefore necessary but not
sufficient when the service meaning of its answers has become stale.
Deferring service RRset changes until the delegation transition has
settled is useful and is often the preferred ordering when it is
feasible. The operational gap is that the point at which the losing
authoritative path is no longer operationally relevant is not a
protocol-visible global event. The change plan needs explicit exit
criteria and evidence, such as relevant parent-side, child-side,
service RRset, and negative-cache TTLs, direct authoritative queries,
DNSSEC validation state, endpoint readiness, and old-path query or
traffic telemetry when available.
Some migrations cannot cleanly separate the authoritative DNS
operator change from the service endpoint cutover. CDN, WAF,
reverse-proxy, or cloud-platform onboarding can require target DNS
data before the target service can complete routing, certificate
Feng, et al. Expires 11 February 2027 [Page 8]
Internet-Draft DNS Operator Endpoint Migration August 2026
issuance, certificate validation, health checks, or tenant
activation. The pre-cutover endpoint can also have a fixed contract,
account, address-allocation, or data-center removal deadline.
Operational project constraints and maintenance windows can also bind
the DNS operator change and service endpoint migration into one
coordinated change. Incident response, DDoS mitigation, or provider
failure can require an endpoint change before all relevant cached
data has expired. In addition, service meaning is not always a
simple IP-address change: CNAME chains, MX, SRV, SVCB, HTTPS, and
service-related TXT RRsets can express dependencies on a target
service platform. In these cases, the service RRset cutover can
occur while the losing authoritative path can still receive queries.
The consequences are resolver-cache-dependent behavior and
operational ambiguity. Users behind one resolver can reach the
target service while users behind another resolver are sent to an old
endpoint that has been removed, released, or no longer accepts the
traffic. Verification points can also observe a parent-side
delegation change but lack a technical signal to distinguish a
planned migration from an unexpected or unauthorized delegation
change.
Public operational reports illustrate the operational risk. A 2025
postmortem for a migration from AWS Route 53 to Cloudflare described
intermittent service interruption involving stale NS data and
negative caching despite preparatory steps and record replication
[NOVU-POSTMORTEM]. The report illustrates why delegation caching,
old authoritative paths, authoritative answer consistency, and
verification during DNS operator migration matter in practice.
The main failure modes are:
* Cached delegation information still sends queries to the losing
DNS operator after the parent-side delegation has changed.
* The losing and gaining DNS operators return materially different
in-scope service RRsets during the service endpoint migration.
* The losing DNS operator stops serving the zone before cached
references to the losing authoritative path have sufficiently
decayed, or inconsistency between the two authoritative paths
creates service failure or security ambiguity.
The practice recommended by this document is to define the in-scope
service RRsets, define the cutover and hold criteria, synchronize
data to both DNS operators or to a common source of truth when both
authoritative paths can still be queried, require the losing DNS
operator to serve correct data during the hold period, directly
Feng, et al. Expires 11 February 2027 [Page 9]
Internet-Draft DNS Operator Endpoint Migration August 2026
compare the losing and gaining authoritative servers, and classify
material inconsistency as a service-risk or unexpected-delegation
condition according to the change plan and authorization state.
5. Operational Model
Figure 1 shows the expected flow. The figure is descriptive; it does
not define a protocol.
Feng, et al. Expires 11 February 2027 [Page 10]
Internet-Draft DNS Operator Endpoint Migration August 2026
+-------------------------------------------------------+
| 1. Prepare and authorize |
| Registrant authorizes roles, timing, endpoint |
| migration, RRset cutover, DNSSEC handling, |
| rollback, consistency profile, and hold period. |
+---------------------------+---------------------------+
|
v
+-------------------------------------------------------+
| 2. Provision and synchronize |
| Losing and gaining operators, or a common source |
| of truth, are provisioned with the service RRsets |
| required for the current phase. |
+---------------------------+---------------------------+
|
v
+-------------------------------------------------------+
| 3. Validate before parent change |
| Endpoint readiness is checked. Losing and |
| gaining authoritative answers are compared. |
+---------------------------+---------------------------+
|
v
+-------------------------------------------------------+
| 4. Change parent-side delegation |
| NS, required glue, and DS data are changed |
| through the registrar/registry path. |
+---------------------------+---------------------------+
|
v
+-------------------------------------------------------+
| 5. Hold while resolvers converge |
| Cached delegation -> losing operator -> target |
| or equivalent data. New delegation -> gaining |
| operator -> target or equivalent data. |
+---------------------------+---------------------------+
|
v
+-------------------------------------------------------+
| 6. Complete and decommission losing service |
| After the hold period and successful verification, |
| decommission the losing hosted zone and revoke |
| unneeded access. |
+-------------------------------------------------------+
Figure 1: Planned Operator Change with Endpoint Migration
The process has six phases:
Feng, et al. Expires 11 February 2027 [Page 11]
Internet-Draft DNS Operator Endpoint Migration August 2026
Preparation
The registrant authorizes the change, identifies the parties,
records the intended parent-side changes, defines the service
endpoint migration and service RRset cutover, determines DNSSEC
handling, prepares rollback, defines the consistency profile, and
sets the hold period.
Provisioning and synchronization
The losing and gaining DNS operators, or a common source of truth
under the registrant's authority, are provisioned so that the in-
scope service RRsets required for the current phase of the plan
are equivalent.
Pre-change validation
The gaining DNS operator and the service endpoints that can
receive traffic in the next planned phase are tested before the
parent-side delegation is changed. The losing and gaining DNS
operators are compared under the consistency profile.
Delegation change
The registrar, registry, or parent-zone operator changes the
parent-side NS RRset, required glue, and DS RRset as specified by
the change plan.
Transition and hold
Resolvers converge toward the new delegation state. During this
period, both the losing and gaining DNS operators continue to
serve target or otherwise equivalent authoritative answers under
the consistency profile.
Completion
After the hold period and after verification indicates that the
losing authoritative path is no longer operationally relevant
under the change plan, the registrant authorizes decommissioning
of the hosted zone at the losing DNS operator and revocation of
unneeded synchronization, provisioning, or other access.
6. Operational Requirements
6.1. Change Plan, Roles, and Authorization
1. An operator change with service endpoint migration MUST be
authorized by the registrant or by a party acting under the
registrant's authority before the parent-side delegation is
changed.
Feng, et al. Expires 11 February 2027 [Page 12]
Internet-Draft DNS Operator Endpoint Migration August 2026
2. The change plan MUST identify the registered domain name, the
losing DNS operator, the gaining DNS operator, the registrar or
other parent-side change path, the intended parent-side NS, glue,
and DS changes, the service endpoint migration, the DNSSEC
handling, the timing of the change, the hold period, and rollback
conditions.
3. The change plan MUST distinguish the role of the authoritative
DNS operator from the role of the registrar or other parent-side
change path. The same organization can perform both roles, but
the operational requirements in this document apply to the
authoritative DNS service and the data it serves.
4. The change plan MUST identify the source of truth for in-scope
service RRsets during the change. The source of truth can be the
losing DNS operator, the gaining DNS operator, a repository or
hidden primary under the registrant's authority, or another
authorized provisioning system.
5. If the change plan follows established migration practice by
changing service endpoint RRsets only after the parent-side
delegation change has settled to an acceptable level of
operational risk, the plan MUST define the evidence used to
decide that the losing authoritative path is no longer
operationally relevant before the service RRset cutover proceeds.
6.2. Consistency Profile and Service RRset Cutover
1. The change plan MUST define a consistency profile for the
operator change and service endpoint migration.
2. The consistency profile MUST identify the names, RR types, DNSSEC
states, expected positive or negative answers, wildcard behavior,
and policy-based answer conditions that are material to the
service endpoint migration.
3. The consistency profile SHOULD include the SOA and NS RRsets
served at the registered domain name, parent-side delegation
data, required address records for authoritative servers, DNSKEY
and DS data when DNSSEC is used, and all in-scope service RRsets
needed to establish service meaning.
4. The service RRset cutover MUST specify which in-scope service
RRsets are correct before and after cutover, whether the cutover
is intended to occur before, during, or after the parent-side
delegation change, and how both DNS operators will receive the
target data when both authoritative paths can still be used.
Feng, et al. Expires 11 February 2027 [Page 13]
Internet-Draft DNS Operator Endpoint Migration August 2026
5. When service RRset cutover is deferred until after the parent-
side delegation change, the consistency profile MUST define the
criteria used to verify that the cutover can proceed within the
risk tolerance specified by the change plan. These criteria
SHOULD include relevant TTLs, direct queries to the losing and
gaining authoritative servers, DNSSEC validation state when
applicable, endpoint readiness, and old-path query or traffic
telemetry when available.
6. Differences that are expected and acceptable during the change
MUST be recorded in the consistency profile. Differences not
recorded in the consistency profile are to be treated as material
differences if they affect RCODE, relevant RRsets, DNSSEC
validity, negative-answer proof when relevant, or service
meaning.
6.3. Synchronization and Change Control
1. Before the parent-side delegation is changed, the losing and
gaining DNS operators MUST have an authorized synchronization
arrangement or MUST receive data from a common authorized source
of truth.
2. Once authorized, the arrangement SHOULD provide a repeatable
provisioning or synchronization path so that in-scope changes do
not depend on ad hoc per-RRset manual coordination by the
registrant.
3. Synchronization mechanisms MUST provide integrity protection and
access control. Zone transfers SHOULD use TSIG or an equivalent
authentication mechanism. API-based or repository-based
provisioning SHOULD use least-privilege credentials, audit
logging, and change controls.
4. During the transition and the hold period, the losing and gaining
DNS operators MUST serve equivalent answers under the consistency
profile, except for differences explicitly recorded in the change
plan.
Feng, et al. Expires 11 February 2027 [Page 14]
Internet-Draft DNS Operator Endpoint Migration August 2026
5. Changes to in-scope service RRsets during the transition and the
hold period MUST be applied through the authorized provisioning
or synchronization arrangement to both DNS operators or to the
common source of truth. If this cannot be done safely, the
change plan MUST state that such changes are either frozen or
subject to a separate emergency procedure. Applying the target
service RRsets only at the gaining DNS operator is not sufficient
while the losing DNS operator can still receive queries because
of cached delegation information, unless the consistency profile
explicitly treats the losing operator's answers as equivalent for
the affected service.
6.4. Parent-Side Delegation Change
1. The parent-side delegation MUST NOT be changed until the gaining
DNS operator has been verified to serve the registered domain
name authoritatively at all planned authoritative server
addresses over UDP and TCP.
2. The parent-side delegation MUST NOT be changed until the service
endpoints that can receive traffic in the next planned phase are
ready, unless the change plan explicitly defines another safe
order. When the service RRset cutover is intentionally deferred
in accordance with established migration practice, those
endpoints can be the pre-cutover service endpoints.
3. NS, required glue, and DS changes SHOULD be treated as one
coordinated change. If the parent-side system cannot update all
relevant data atomically, the change plan MUST define an order
that preserves reachability and DNSSEC validity at each step.
6.5. Service Continuity and Hold Period
1. The losing DNS operator MUST continue to serve the registered
domain name during the transition and the hold period unless an
explicitly documented rollback or emergency action supersedes the
plan.
2. During the hold period, the losing DNS operator MUST continue to
serve target or otherwise equivalent in-scope service RRsets
under the consistency profile. It MUST NOT continue to serve
stale pre-cutover service RRsets unless the change plan
explicitly records that those answers remain equivalent for the
affected service.
3. The hold period MUST be long enough to cover the maximum relevant
TTLs for parent-side NS and DS RRsets, the SOA and NS RRsets
served at the registered domain name, DNSKEY RRsets when DNSSEC
Feng, et al. Expires 11 February 2027 [Page 15]
Internet-Draft DNS Operator Endpoint Migration August 2026
is used, authoritative-server address RRsets, in-scope service
RRsets, and negative answers that can affect the migration, plus
an operational safety margin.
4. For zones for which failure would have significant security,
availability, or business impact, the hold period SHOULD be
measured in days rather than hours. When no traffic telemetry or
zone-specific risk model is available, a conservative hold period
of multiple days is RECOMMENDED.
5. During the hold period, the losing DNS operator SHOULD continue
to serve an NS RRset for the registered domain name that is
consistent with the NS RRset served by the gaining DNS operator,
even if the parent has already stopped delegating to the losing
DNS operator.
6.6. DNSSEC
1. If the zone is signed, the change plan MUST specify the DNSSEC
model used for the operator change. The model can be a single-
signer model, a multi-signer model, a temporary unsigned state
where policy permits it, or another model that preserves
validation.
2. The timing of DS, DNSKEY, RRSIG, NSEC, and NSEC3 changes MUST be
coordinated so that validating resolvers have a valid
authentication path throughout the transition and the hold
period.
3. If both DNS operators independently sign the zone, the DNSSEC
configuration SHOULD follow multi-signer practices such as those
described in [RFC8901]. In particular, the DNSKEY and DS states
need to allow validation regardless of which DNS operator
answers.
6.7. Policy-Based Answers
1. If the zone uses policy-based or dynamic answers, including
geography-based policies, EDNS Client Subnet, health-checked
answers, failover, ALIAS-like processing, SVCB or HTTPS
synthesis, or online signing, the change plan MUST describe how
equivalent behavior is provided or which differences are
accepted.
2. Verification for policy-based answers SHOULD include multiple
vantage points or test inputs when a single vantage point cannot
observe the relevant answer policy.
Feng, et al. Expires 11 February 2027 [Page 16]
Internet-Draft DNS Operator Endpoint Migration August 2026
6.8. Verification and Risk Classification
1. Verification points SHOULD collect a baseline before the parent-
side delegation is changed. The baseline should include parent-
side delegation data, data served by the losing and gaining DNS
operators, SOA serials or version identifiers, in-scope service
RRsets, endpoint readiness state, and DNSSEC validation status
when applicable.
2. Verification points SHOULD directly query both the losing and
gaining DNS operators during the transition and the hold period.
Relying only on ordinary recursive resolution can hide
differences caused by cache state or resolver server-selection
behavior.
3. If a parent-side delegation changes without a corresponding
authorized change plan, verification points SHOULD classify the
event as an unexpected-delegation condition.
4. If a parent-side delegation changes according to an authorized
plan and the losing and gaining DNS operators serve equivalent
answers under the consistency profile, verification points MAY
classify the event as consistent with a planned operator change,
subject to other local policy and risk inputs.
5. If the losing and gaining DNS operators serve materially
different answers during the transition or hold period, or if the
losing DNS operator stops serving correct data before the hold
period ends, verification points SHOULD classify the event as a
service-risk condition. If the discrepancy is not authorized by
the registrant, verification points SHOULD also classify the
event as a possible unexpected-delegation or service-compromise
condition.
7. Using Consistency Evidence for Risk Classification
The procedure in this section turns authoritative data consistency
into technical evidence for risk classification. It is not merely a
conformance test for the operator change process. A verification
point uses the change plan, the parent-side delegation state, and
direct authoritative queries to classify an observed state as
consistent with a planned operator change, as a service-risk
condition, or as potentially unauthorized.
A verification point can use the following procedure:
Feng, et al. Expires 11 February 2027 [Page 17]
Internet-Draft DNS Operator Endpoint Migration August 2026
1. Load the change plan and derive the consistency profile. If no
authorized change plan exists for the registered domain name,
record the absence of a plan as an input to the unexpected-
delegation classification.
2. Query the parent-side authoritative servers for the current NS,
DS, and required glue state of the registered domain name.
3. Query every planned authoritative server address at the losing
and gaining DNS operators for the names and RR types in the
consistency profile. The queries should cover the transports and
DNSSEC inputs needed by the consistency profile.
4. Normalize responses for comparison according to the consistency
profile. Normalization can ignore non-semantic differences such
as message IDs, RR ordering, case differences in names, or
optional EDNS data. It should not ignore RCODE, authoritative-
answer status, relevant RRsets, negative-answer proof when
relevant, DNSSEC validity, or service meaning.
5. Validate DNSSEC chains when the zone is signed. This includes
the parent DS state, the child DNSKEY RRset, RRSIG validity, and
authenticated denial of existence for relevant negative answers.
6. Compare the results against the change plan and consistency
profile. Differences that are not allowed by the profile should
be reported with the query name, RR type, target server, response
summary, and validation status.
7. Classify the observed state. At a minimum, implementations
SHOULD distinguish among the following states: no authorized plan
for a delegation change, a planned change with equivalent data, a
planned change with material inconsistency, an attempt to perform
a deferred service RRset cutover before its criteria are met,
early loss of service at the losing DNS operator, and DNSSEC
validation risk.
8. Repeat the procedure during the hold period from multiple vantage
points when possible. Multiple vantage points are especially
useful for anycast, geography-based policy, provider-specific
filtering, and network-specific reachability issues.
This procedure does not prove that a change is authorized. It
supplies technical evidence that can be combined with authorization
records, registrar or registry logs, DNS operator logs, DNSSEC state,
service telemetry, and account-security evidence. A verification
point can map the classifications in this section to one or more
local alert types.
Feng, et al. Expires 11 February 2027 [Page 18]
Internet-Draft DNS Operator Endpoint Migration August 2026
8. Example Timeline
The following example illustrates an unsigned or single-signer zone
in which the service RRset cutover occurs before the parent-side
delegation change. The registered domain name changes authoritative
DNS operators while its web service moves from an old hosting
environment to a new hosting environment. Documentation addresses
from [RFC5737] are used in the example. The exact timing depends on
TTLs, signature validity, operational risk, and local policy.
T-7 days
The registrant approves the change plan. The consistency profile
includes the parent-side NS and DS data, the child-side SOA and NS
RRsets, "www.example.com" A and AAAA RRsets, relevant CNAME-chain
data if used, representative negative answers if they affect the
migration, and DNSSEC state when applicable. The gaining DNS
operator loads the zone. The losing and gaining DNS operators
establish synchronization or are both provisioned from the common
source of truth. TTLs that materially affect the change are
lowered where appropriate.
T-2 days
The new web service endpoint is ready to receive traffic. The
target A RRset for "www.example.com" is changed from 192.0.2.10 to
198.51.100.10 in the authorized source of truth. Both the losing
and gaining DNS operators serve the target data under the
consistency profile. Verification points confirm that the gaining
DNS operator is reachable over UDP and TCP and that the losing and
gaining DNS operators serve equivalent answers.
T
The registrar, registry, or parent-zone operator updates the
parent-side NS, required glue, and DS data according to the change
plan.
T to T+7 days
Recursive resolvers converge at different times. Some resolvers
still query the losing DNS operator, while others query the
gaining DNS operator. Both operators continue to serve target or
otherwise equivalent data. New in-scope service RRset changes are
applied through the common source of truth or synchronized to both
DNS operators. Verification points continue comparing the old and
new authoritative paths and classifying observed states.
T+7 days or later
If the hold period has elapsed, verification has found no material
inconsistencies, DNSSEC data is valid, service telemetry is
acceptable, and traffic or query telemetry for the losing
Feng, et al. Expires 11 February 2027 [Page 19]
Internet-Draft DNS Operator Endpoint Migration August 2026
authoritative path is acceptable under local policy, the
registrant authorizes the losing DNS operator to remove the zone
and revoke unneeded access.
A migration following established DNS hosting practices can instead
defer the service RRset cutover until after the parent-side
delegation change has reached the risk tolerance specified by the
change plan. In that case, the same consistency profile and
verification procedure are used to determine when the service RRset
cutover can proceed.
9. Operational Considerations
The parent-side delegation change is not the end of the operator
change. Operators should treat completion as a separate phase that
follows cache convergence, verification, and the hold period.
The losing DNS operator's commercial service end date should be later
than the technical hold period. If the commercial service is
terminated at the same time the parent-side delegation is changed,
automated account cleanup can remove the zone before resolvers have
stopped using the old path.
Endpoint readiness needs to be part of the DNS change plan. DNS data
that is syntactically correct can still be operationally wrong if it
points to an endpoint that is not yet ready, has already been
removed, or no longer belongs to the registrant.
A zone that uses in-domain authoritative server names needs
particular care. Address records and glue related to the old
authoritative server names can remain in caches, and the hosting
arrangements for those addresses might also be affected by account
changes, hosting changes, or address reuse.
If the DNS operators use anycast, response-rate limiting, access-
control lists, DDoS filtering, or geography-based policy,
verification from a single vantage point is not sufficient to
establish global consistency. A common source of truth is
operationally preferable when it exists, because it reduces the
chance that emergency content changes are applied at one operator but
not the other.
Feng, et al. Expires 11 February 2027 [Page 20]
Internet-Draft DNS Operator Endpoint Migration August 2026
10. Security Considerations
This document is intended to reduce availability failures and to
improve detection of unexpected delegation changes for registered
domain names during service endpoint migration. It does not replace
account security, registry lock mechanisms, registrar authentication,
DNSSEC, change approval, or incident response.
The synchronization path is security-critical. If an attacker can
modify the common source of truth or compromise API credentials, a
zone-transfer channel, or a provisioning workflow, the attacker can
cause both DNS operators to serve consistent but malicious data.
Synchronization and provisioning systems therefore require strong
authentication, least-privilege access, audit logging, and timely
credential revocation.
The hold period creates a useful comparison point for classification,
but it also prolongs the lifetime of old accounts, old credentials,
zone-transfer permissions, and operational dependencies. The hold
period should be long enough to support cache convergence and risk
detection, but it should not become an indefinite second production
path unless that is the registrant's explicit multi-provider design.
If an attacker changes only the parent-side delegation, a comparison
against data still served by the losing DNS operator can reveal a
material discrepancy. If the attacker also controls the registrant's
approval path, both DNS operators, or the common source of truth, the
mechanism described here might not detect the attack.
Verification classifications can have both false positives and false
negatives. Operational mistakes, incomplete consistency profiles,
policy-based answers, partial anycast failures, and reachability
filtering can produce apparent inconsistency during an authorized
change. Conversely, an attacker who controls both the parent-side
change path and the synchronized zone content can make the losing and
gaining DNS operators appear consistent. Classifications produced
using this document should therefore be combined with registry,
registrar, DNS operator, DNSSEC, service telemetry, and account-
security evidence.
Verification traffic should be rate limited and coordinated where
appropriate. Excessive direct queries to all authoritative server
addresses can be mistaken for abuse or can create avoidable load.
Feng, et al. Expires 11 February 2027 [Page 21]
Internet-Draft DNS Operator Endpoint Migration August 2026
11. Privacy Considerations
Verification queries can reveal that a zone is undergoing an operator
change and a service endpoint migration, and can reveal which names
the registrant considers important. Verification profiles should
avoid sensitive names that are not necessary and should limit query
frequency to what is operationally useful.
Change plans can contain sensitive data, including contacts, timing,
internal ticket numbers, rollback conditions, endpoint details, and
provider details. Such plans should be shared only with parties that
need them. Public incident reports or transparency logs should
remove credentials, sensitive contact information, and unnecessary
internal identifiers.
12. IANA Considerations
This document has no IANA actions.
13. Normative References
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<https://www.rfc-editor.org/info/rfc1034>.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <https://www.rfc-editor.org/info/rfc1035>.
[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/info/rfc2119>.
[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/info/rfc8174>.
[RFC9499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
Terminology", BCP 219, RFC 9499, DOI 10.17487/RFC9499,
March 2024, <https://www.rfc-editor.org/info/rfc9499>.
14. Informative References
Feng, et al. Expires 11 February 2027 [Page 22]
Internet-Draft DNS Operator Endpoint Migration August 2026
[AWS-ROUTE53-MIGRATION]
Amazon Web Services, "Migrating a hosted zone to a
different AWS account",
<https://docs.aws.amazon.com/Route53/latest/
DeveloperGuide/hosted-zones-migrating.html>.
[NOVU-POSTMORTEM]
Novu, "Postmortem on DNS Name Server Migration
Interruption", March 2025, <https://novu.co/blog/
postmortem-on-dns-name-server-migration-interruption/>.
[RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995,
DOI 10.17487/RFC1995, August 1996,
<https://www.rfc-editor.org/info/rfc1995>.
[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS
NCACHE)", RFC 2308, DOI 10.17487/RFC2308, March 1998,
<https://www.rfc-editor.org/info/rfc2308>.
[RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D., and B.
Wellington, "Secret Key Transaction Authentication for DNS
(TSIG)", RFC 2845, DOI 10.17487/RFC2845, May 2000,
<https://www.rfc-editor.org/info/rfc2845>.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements",
RFC 4033, DOI 10.17487/RFC4033, March 2005,
<https://www.rfc-editor.org/info/rfc4033>.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, DOI 10.17487/RFC4034, March 2005,
<https://www.rfc-editor.org/info/rfc4034>.
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Protocol Modifications for the DNS Security
Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005,
<https://www.rfc-editor.org/info/rfc4035>.
[RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
Security (DNSSEC) Hashed Authenticated Denial of
Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008,
<https://www.rfc-editor.org/info/rfc5155>.
[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/info/rfc5731>.
Feng, et al. Expires 11 February 2027 [Page 23]
Internet-Draft DNS Operator Endpoint Migration August 2026
[RFC5737] Arkko, J., Cotton, M., and L. Vegoda, "IPv4 Address Blocks
Reserved for Documentation", RFC 5737,
DOI 10.17487/RFC5737, January 2010,
<https://www.rfc-editor.org/info/rfc5737>.
[RFC5936] Lewis, E. and A. Hoenes, "DNS Zone Transfer Protocol
(AXFR)", RFC 5936, DOI 10.17487/RFC5936, June 2010,
<https://www.rfc-editor.org/info/rfc5936>.
[RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC
Operational Practices, Version 2", RFC 6781,
DOI 10.17487/RFC6781, December 2012,
<https://www.rfc-editor.org/info/rfc6781>.
[RFC7344] Kumari, W., Gudmundsson, O., and G. Barwood, "Automating
DNSSEC Delegation Trust Maintenance", RFC 7344,
DOI 10.17487/RFC7344, September 2014,
<https://www.rfc-editor.org/info/rfc7344>.
[RFC7477] Hardaker, W., "Child-to-Parent Synchronization in DNS",
RFC 7477, DOI 10.17487/RFC7477, March 2015,
<https://www.rfc-editor.org/info/rfc7477>.
[RFC8078] Gudmundsson, O. and P. Wouters, "Managing DS Records from
the Parent via CDS/CDNSKEY", RFC 8078,
DOI 10.17487/RFC8078, March 2017,
<https://www.rfc-editor.org/info/rfc8078>.
[RFC8901] Huque, S., Aras, P., Dickinson, J., Vcelak, J., and D.
Blacka, "Multi-Signer DNSSEC Models", RFC 8901,
DOI 10.17487/RFC8901, September 2020,
<https://www.rfc-editor.org/info/rfc8901>.
Acknowledgements
TBD.
Authors' Addresses
Yuming Feng
Pengcheng Laboratory
Email: fengym@pcl.ac.cn
Yu Zhang
Harbin Institute of Technology
Email: yuzhang@hit.edu.cn
Feng, et al. Expires 11 February 2027 [Page 24]
Internet-Draft DNS Operator Endpoint Migration August 2026
Di Ma
ZDNS
Email: madi@zdns.cn
Weizhe Zhang
Harbin Institute of Technology
Email: wzzhang@hit.edu.cn
Rongwei Yang
Pengcheng Laboratory
Email: yangrw@pcl.ac.cn
Feng, et al. Expires 11 February 2027 [Page 25]