Introduction

A nameserver migration can look correct in the zone file while the domain still follows the old IP because the glue records were never updated properly. This usually affects domains using child nameservers such as ns1.example.com, where the parent registry still tells resolvers to use the previous IP even though the authoritative server itself was moved.

Treat this as a delegation problem instead of a normal propagation delay. Start by checking the current glue IP published at the registrar or parent zone, because changing the zone on the nameserver does not update the child nameserver host record automatically.

Symptoms

  • The domain still resolves through the old nameserver IP after migration
  • Zone changes on the new nameserver do not affect live resolution
  • Parent delegation still points queries toward the previous server
  • Some lookups show the new nameserver hostnames but the old IP addresses
  • The issue starts after moving child nameservers to a new server or provider
  • Regular DNS records look correct in the zone, but the domain still behaves as if the old DNS host is active

Common Causes

  • The registrar host record for the child nameserver was never updated
  • Only the zone file changed while the parent glue data remained old
  • One nameserver glue IP was updated while another stayed on the previous address
  • The domain uses in-domain nameservers and still depends on stale parent delegation
  • The nameserver migration was done in the wrong order and left mixed glue data
  • Cached delegation information still reflects an incomplete registrar-side update

Step-by-Step Fix

  1. Identify whether the domain uses child nameservers such as ns1.yourdomain.com, because glue-IP problems apply specifically to in-domain nameserver host records.
  2. Check the current host-record or glue-IP values at the registrar for each affected child nameserver, because the parent zone controls which IP resolvers use to reach those nameservers.
  3. Compare the registrar glue IPs with the actual IPs of the new nameserver host, because a mismatch there means the migration is incomplete even if the zone itself looks correct.
  4. Verify that every listed child nameserver was updated and not just one of them, because mixed glue data can make resolution alternate unpredictably between old and new DNS infrastructure.
  5. Confirm that the domain delegation still points to the intended child nameservers after the migration, because updating glue without checking the delegation set can leave the domain using an outdated path.
  6. Retest authoritative resolution after the registrar-side change rather than relying only on cached recursive lookups, because delegation updates are easiest to confirm at the source.
  7. Check whether the old nameserver is still answering authoritatively for the zone and remove that dependency when safe, because leaving the legacy server live can hide whether the glue update actually worked.
  8. Re-test from multiple external resolvers after the glue fix is published, because cached parent-side data can make one resolver look updated while another still follows the old IP.
  9. Document the final child nameserver hostnames and glue IPs after recovery, because glue records are a frequent failure point in future nameserver migrations.