Introduction

A DNS provider migration can update the main zone successfully while secondary DNS servers still serve the pre-cutover version. The new provider may already hold the intended records and one direct check may look correct, but some resolvers continue receiving answers from secondaries that never switched to the new primary data source.

Treat this as a secondary-authority problem instead of a generic propagation delay. Start by checking which authoritative servers still return the older zone contents, because a migration can appear complete while one or more secondaries keep serving a stale copy from the previous hidden primary or transfer source.

Symptoms

  • Secondary DNS still serves the pre-cutover zone after provider migration
  • Some resolvers return the new records while others still return the old zone data
  • The SOA or record answers differ between authoritative nameservers for the same zone
  • Changes made at the new provider do not appear consistently across all authoritative servers
  • DNS looks partly migrated, but old IPs or old MX hosts still appear from some paths
  • The issue started after DNS provider migration, hidden primary change, or authoritative server replacement

Common Causes

  • Secondary DNS still pulls from the old primary or hidden primary source
  • Zone transfer settings were not updated after the provider migration
  • The new provider contains the correct zone, but secondaries still serve an older copy
  • SOA serial handling or transfer triggers did not move cleanly to the new primary design
  • Teams validated the new zone contents but not the behavior of every authoritative server
  • A mixed DNS design left some secondaries under separate operational control during cutover

Step-by-Step Fix

  1. Query each authoritative nameserver for the affected zone and compare the answers, because you need to confirm exactly which secondary servers still serve the pre-cutover data.
  2. Check the SOA record and serial returned by each authoritative server, because differences there usually reveal whether the old zone is still being served from a stale transfer source.
  3. Review the current primary or hidden primary definition used by the secondary DNS platform, because secondaries often stay pointed at the old source even when the visible provider has changed.
  4. Compare zone transfer permissions, NOTIFY behavior, and source IP expectations between the old and new provider, because secondaries cannot update correctly if they still trust or poll the wrong primary.
  5. Update the real transfer source for the secondary servers only after confirming the new primary serves the correct full zone, because changing the source prematurely can spread broken data.
  6. Trigger or allow a fresh transfer from the intended new primary and confirm the secondary now loads the current zone data, because the fix is complete only when the stale copy is replaced.
  7. Recheck every authoritative server and verify they now return matching answers and SOA values, because one corrected node does not prove the full authoritative set is aligned.
  8. Test the live hostname or record path that exposed the issue and confirm it no longer returns pre-cutover data, because operational recovery matters more than a single transfer success message.
  9. Document the final primary-secondary design and transfer source after recovery, because mixed authoritative setups are easy to misread during future DNS migrations.