| Internet-Draft | DNS Operator Endpoint Migration | August 2026 |
| Feng, et al. | Expires 11 February 2027 | [Page] |
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.¶
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 11 February 2027.¶
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.¶
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 whether a change is authorized, but it can help verification points distinguish a planned migration from operational failure or a possible unauthorized delegation change.¶
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:¶
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.¶
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.¶
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 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:¶
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 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.¶
Figure 1 shows the expected flow. The figure is descriptive; it does not define a protocol.¶
+-------------------------------------------------------+
| 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. |
+-------------------------------------------------------+
The process has six phases:¶
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:¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
This document has no IANA actions.¶
TBD.¶