Nameservers, glue records and DNS propagation: who answers for your domain?

Picture an office building with a busy lobby. Visitors ask where a company is located, and the lobby desk answers from the official directory. Your domain is the building name, DNS records are suite numbers and mailroom instructions, and authoritative nameservers are the desks permitted to answer for that directory.

Changing one DNS record edits a note inside the directory. Changing nameservers changes who operates the entire desk. That distinction explains why an incomplete nameserver migration can leave the website working while email, certificate validation or another service disappears.

Nameservers versus DNS records

The registrar and DNS host may be the same company, but they perform different roles. Registration identifies the holder and communicates delegation to the registry; authoritative DNS publishes the live answers. Nameserver settings form the bridge between ownership of the name and the systems that answer for it.

Authoritative servers know; recursive resolvers ask

An authoritative nameserver is an official source for a zone. It can return the A record for www.example.com or an authoritative statement that the name does not exist. A recursive resolver works for the user, follows the hierarchy from root to TLD to the domain’s delegation, and caches the answer so every page load does not repeat the entire journey.

• A device asks its configured recursive resolver for www.example.com. A device asks its configured recursive resolver for www.example.com.
• The resolver follows the hierarchy until it identifies the authoritative nameservers. The resolver follows the hierarchy until it identifies the authoritative nameservers.
• An authoritative server returns the requested answer or a negative response. An authoritative server returns the requested answer or a negative response.
• The resolver caches that result according to its TTL and gives it to the device. The resolver caches that result according to its TTL and gives it to the device.

You control the authoritative zone and the delegation published for your domain. You do not control every resolver or the moment at which each one cached the former answer. That asymmetry creates the mixed-view period during a cutover.

What changing nameservers at the registrar really does

Replacing the old nameserver list in the registrar does not rewrite caches worldwide. It asks the registrar and registry to update the parent delegation: the pointer that tells resolvers which servers should answer for the child domain.

• Create or import the complete zone at the new DNS host before changing delegation. Create or import the complete zone at the new DNS host before changing delegation.
• Copy the nameserver hostnames supplied by that host into the registrar. Copy the nameserver hostnames supplied by that host into the registrar.
• The registrar submits the delegation change to the registry according to the TLD process. The registrar submits the delegation change to the registry according to the TLD process.
• Once the parent publishes it, resolvers without a reusable old delegation ask the new servers. Once the parent publishes it, resolvers without a reusable old delegation ask the new servers.
• Resolvers still holding old NS data or old record answers continue using them until expiry. Resolvers still holding old NS data or old record answers continue using them until expiry.

Two clocks matter: acceptance and publication by the registrar or registry, and the remaining lifetime of cached delegations and answers. Never delete the old zone immediately after Save; some resolvers may still ask the former servers even though the control panel already displays the new names.

Glue records: when the desk lives inside the building

Suppose example.com delegates to ns1.example.com and ns2.example.com. A resolver needs an IP address to contact ns1, but asking for that address would normally require contacting the nameservers for example.com—the very servers it cannot yet reach. This circular dependency needs bootstrap data.

Glue is an A or AAAA address the parent publishes alongside the NS delegation. It is generally needed for in-bailiwick nameservers whose hostnames fall inside the delegated namespace. Names such as ns1.provider.net are resolved through the provider’s separate zone and normally do not require custom glue at your registrar.

• Registrar panels may call glue a host record, child nameserver, personal nameserver or registered nameserver. Registrar panels may call glue a host record, child nameserver, personal nameserver or registered nameserver.
• When a nameserver address changes, update both parent-side glue and the A or AAAA record inside the zone. When a nameserver address changes, update both parent-side glue and the A or AAAA record inside the zone.
• Glue is only a bootstrap hint; the authoritative zone should still publish the truthful address for that hostname. Glue is only a bootstrap hint; the authoritative zone should still publish the truthful address for that hostname.

TTL: the expiration time on a cached answer

TTL is expressed in seconds and tells a resolver how long it may reuse DNS data. A value of 3600 represents about one hour and 86400 about one day. Low values such as 300 can make a planned record cutover more responsive, but keeping them permanently increases query volume without removing every other cache involved in delegation.

Lowering a TTL does not rewrite copies already cached with the former higher value. Make the reduction early enough for that old lifetime to drain, then restore sensible production TTLs after stability. Remember that record TTLs inside the child zone and delegation TTLs at the parent are separate.

DNS propagation: myths and reality

Propagation is not a wave copying your complete zone to every computer. You publish authoritative data; resolvers learn it when they need an answer and no longer have a reusable cached one. Networks switch at different moments because they asked at different moments and have different remaining cache lifetimes.

A more accurate status message is: “We are waiting for existing caches to expire; some networks will switch sooner than others.” That sentence describes the mechanism without promising an arbitrary deadline.

How to verify with dig and nslookup

Verification should ask more than one place and should include the servers expected to be authoritative. dig is common on Linux and macOS, while nslookup is broadly available, including on Windows. The goal is not to memorize every flag but to separate parent delegation, authoritative truth and resolver cache.

If you prefer a browser interface, SoxDomains DNS Lookup can query the public records without requiring command-line access. Use it as one viewpoint alongside direct authoritative queries, not as a replacement for checking each listed nameserver. Use the free SoxDomains DNS Lookup

1. Ask what the parent publishes

Query the domain’s NS records and, when available, trace the delegation. Confirm the parent publishes the exact new nameserver set after the registrar or registry accepts the update. Check the domain with SoxDomains WHOIS and RDAP

2. Ask every new authoritative server directly

Query the apex, www, MX and critical TXT records against each listed server. If one server has an incomplete or older zone, users may fail intermittently depending on which authoritative server their resolver contacts.

3. Compare the former authoritative service

During overlap, the old and new services should return compatible production answers. Differences reveal records not copied or intentionally changed; document which is which before assuming every mismatch is cache.

4. Sample recursive resolvers and real networks

A public resolver provides one additional viewpoint, not a worldwide verdict. Test a cellular connection, office network and another ISP when the change matters. Online propagation checkers are useful samples but cannot represent every cache.

Common mistakes and their real symptoms

Orphaned or stale glue

The zone says ns1 has a new address while parent glue still points to a retired machine. Some lookup paths reach the new server and others knock on an empty address. Treat glue as production data and update or remove it whenever in-domain nameserver addresses change.

Half-cutover

The new zone includes the website A record but omits MX, DKIM or a SaaS verification TXT. The site works while email or another service fails. Inventory and copy the living zone, not only the front door.

Low TTL left forever

A temporary 300-second TTL remains for months. Nothing dramatic happens, but authoritative query volume stays higher and every accidental edit becomes visible quickly. Lower before the move, raise after it and put the restoration on the migration checklist.

Deleting the old zone too early

The registrar shows the new nameservers, so the old service is removed immediately. Resolvers still holding the old delegation now receive failures. Keep the former authoritative zone alive through the expected cache tail and verified stability period.

Editing the wrong DNS panel

The domain delegates to Host A while someone edits a convenient panel at Host B or the registrar’s inactive default zone. The save succeeds but the internet never asks that service. Look up the current authoritative NS before editing.

Changing every layer at once

Nameservers, web addresses and mail routing change together while high TTLs remain. When a service fails, there is no clean way to identify the layer. Build and verify the new zone first, change delegation once, observe, and decommission later.

Practical cutover checklist

A few days before

• List website, mail, admin names, SaaS verification, CDN names and every service using the domain. List website, mail, admin names, SaaS verification, CDN names and every service using the domain.
• Export or capture the current zone and record the old nameservers. Export or capture the current zone and record the old nameservers.
• Record current TTLs and lower the records that will change early enough for old values to drain. Record current TTLs and lower the records that will change early enough for old values to drain.
• Create the complete zone at the new host, including mail and verification data. Create the complete zone at the new host, including mail and verification data.

Before the flip

• Query each new authoritative server directly for apex, www, MX and key TXT records. Query each new authoritative server directly for apex, www, MX and key TXT records.
• Prepare parent-side glue and matching zone addresses for in-domain nameservers. Prepare parent-side glue and matching zone addresses for in-domain nameservers.
• Confirm access to registrar, old DNS and new DNS accounts. Confirm access to registrar, old DNS and new DNS accounts.
• Tell stakeholders that some networks may switch sooner than others. Tell stakeholders that some networks may switch sooner than others.

The flip

• Update the registrar nameserver list and required glue once. Update the registrar nameserver list and required glue once.
• Keep the old zone active. Keep the old zone active.
• Wait for registrar or registry acceptance and inspect the parent delegation. Wait for registrar or registry acceptance and inspect the parent delegation.
• Recheck critical records directly against every new server. Recheck critical records directly against every new server.

After the flip

• Compare new servers, old servers and at least one recursive resolver. Compare new servers, old servers and at least one recursive resolver.
• Test real clients on cellular, office and another available network. Test real clients on cellular, office and another available network.
• Keep the former service answering until the cache tail has passed. Keep the former service answering until the cache tail has passed.
• Restore sensible TTLs, remove stale glue and document date, old NS, new NS and glue addresses. Restore sensible TTLs, remove stale glue and document date, old NS, new NS and glue addresses.

If something looks wrong

• Identify the failed layer: parent delegation, incomplete zone, stale glue or a still-valid resolver cache. Identify the failed layer: parent delegation, incomplete zone, stale glue or a still-valid resolver cache.
• Fix authoritative truth first; waiting cannot restore a missing MX record. Fix authoritative truth first; waiting cannot restore a missing MX record.
• Do not flip nameservers back and forth every few minutes. Do not flip nameservers back and forth every few minutes.

A short story of a clean move

Maria runs a studio website. On Monday she copies every record to the new DNS host, lowers the records that will change and queries the new nameservers directly until web, mail and verification answers match. On Wednesday she updates the registrar to the provider’s out-of-zone nameservers, so custom glue is unnecessary, and leaves the old DNS service untouched.

On Thursday her phone and office show the new path while one client continues seeing the former address until midday. That is an expected cached viewpoint, not evidence that she must save the registrar form again. On Friday she restores normal TTLs, documents the move and schedules removal of the old zone only after the overlap period.

Putting the model together

Nameservers identify who may answer; records are what those servers say; recursive resolvers ask and remember; glue supplies a bootstrap address when the nameserver lives inside the delegated name; TTL limits reuse; and propagation is mostly those cached notes expiring at different times.

Build and verify the new authoritative zone first, change the registrar delegation second, keep the old desk open while caches move and verify with deliberate queries rather than intuition. If the domain is also moving between registrars, separate that transfer from the DNS migration when possible so fewer variables change at once. Plan a domain transfer

Country-code registries may validate reachability, require a certain server count or apply their own delegation policies. Review the specific extension requirements rather than assuming every ccTLD behaves like .com. Compare ccTLD requirements