Pengcheng Laboratory

fengym@pcl.ac.cn

Harbin Institute of Technology

yuzhang@hit.edu.cn

ZDNS

madi@zdns.cn

Harbin Institute of Technology

wzzhang@hit.edu.cn

Pengcheng Laboratory

yangrw@pcl.ac.cn

Internet DNSOP Working Group DNS authoritative DNS registered domain name delegation DNSSEC operations 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.

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 whether a change is authorized, but it can help verification points distinguish a planned migration from operational failure or a possible unauthorized delegation change.

Scope and Relation to Existing Work This document assumes the DNS concepts and protocol behavior defined in and . 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 . 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:

• describes DNS negative caching, which can affect migration timing when resolvers cache NXDOMAIN or NODATA responses.
• , , , , and describe DNSSEC protocol and operational practices, including authenticated denial of existence and changes between cooperating and non-cooperating DNS operators.
• describes multi-signer DNSSEC models for zones served by multiple DNS providers.
• , , and describe in-band signaling for child-to-parent updates of DS, DNSKEY, NS, and glue-related data.
• , , and describe DNS zone transfer and transaction authentication mechanisms that can be used in some synchronization arrangements.
• 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 . 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.

Conventions and Terminology

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

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

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 .

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.

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.

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

Operational Model Figure 1 shows the expected flow. The figure is descriptive; it does not define a protocol.

Planned Operator Change with Endpoint Migration 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:

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.

Operational Requirements

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

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

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

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.

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

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 . In particular, the DNSKEY and DS states need to allow validation regardless of which DNS operator answers.

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.

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.

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:

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.

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

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.

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.

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.

IANA Considerations This document has no IANA actions.

Normative References Informative References Amazon Web Services Novu

Acknowledgements TBD.