A new DNS provider can serve the correct record while some users still reach the old endpoint. Their resolvers may have cached an earlier answer. If the name previously did not exist, they may even have cached that negative response. A dashboard that reports a successful save tells you the provider accepted the change. The behavior of clients depends on delegation and caches further down the path.
For that reason, evaluate DNS management tools around the changes you need to make safely. Creating a record is straightforward. Moving a zone with mail, certificate validation, and private names requires more care.
Identify who controls the answer
The registrar is typically where you manage the domain’s delegation. An authoritative DNS provider serves records for the delegated zone. A recursive resolver looks up and caches answers on behalf of clients. These roles can be handled by separate services. Map them before changing providers, especially if internal resolvers and public resolvers return different answers for the same name.
Inventory the records and the systems that write them. Include mail routing, sender authentication, certificate validation, delegated subdomains, and wildcard records. Record any provider-specific aliases or routing policies separately. A plain zone export may not capture how a provider turns those features into answers.
Where the providers differ
| Platform | Reason to evaluate it | Migration question |
|---|---|---|
| Cloudflare DNS | It combines authoritative DNS with optional proxying for eligible records. | Which records should be proxied, and which must remain DNS-only? |
| Amazon Route 53 | It offers routing policies such as weighted and failover routing. | How will health checks and cached responses affect traffic during a change? |
| Azure DNS | It offers public zone hosting and private DNS options for Azure environments. | Which virtual networks and resolvers must be able to answer private names? |
The Cloudflare proxy status guide explains the traffic-path consequences of proxying. The Route 53 routing policy guide and Azure DNS overview help distinguish routing features from private resolution requirements.
Run the cutover in stages
- Build the new zone and compare responses directly from the old and new authoritative nameservers before changing delegation.
- Where shorter caching is part of the plan, lower relevant TTLs early enough for previously cached answers to age out. If DNSSEC is enabled, plan the parent DS record and signing transition before changing nameservers.
- After cutover, check public and private resolution from the networks that actually use the domain. Verify application traffic and mail delivery alongside DNS answers.
- Keep the old zone available during the transition. Reversing delegation is itself a DNS change and may take time to reach every resolver.
For the evaluation, try changing a low-risk subdomain and recovering it using the records and access available to the on-call team. That exercise exposes the operational details that matter most, from record-level audit history to whether an operator can identify an old cached answer.