Two Places Your Nameservers Are Written Down
Query your domain's NS records and you get an answer. Query them a different way and you can get a different answer.
That's not a bug. NS records exist in two places, maintained by two different parties, and they're supposed to match. When they don't, you get the class of DNS problem that resolves for some people and not others, and that no amount of staring at your DNS control panel will explain.
The Parent and the Child
The parent zone — in most cases the TLD's nameservers, run by the registry — holds a delegation. When you set nameservers at your registrar, the registrar tells the registry, and the registry publishes NS records in the TLD zone pointing at your nameservers.
example.com. NS ns1.provider.net.
example.com. NS ns2.provider.net.
These records are what a resolver finds when it walks down from the root. They're non-authoritative — the parent is delegating, not asserting.
The child zone — your own zone, on your own nameservers — also contains NS records at the apex. These are authoritative: they're your zone's own statement about who serves it.
Both sets should list the same nameservers. A resolver following the delegation arrives at your nameservers and typically caches the authoritative set it finds there.
When They Disagree
The NS Lookup tool queries nameserver records:
- Enter the domain.
- Read the returned nameservers.
The diagnostic step worth taking: compare what the parent says against what your own nameservers say. A mismatch produces symptoms that look random.
Common mismatch scenarios:
You changed nameservers at your DNS provider but not at the registrar. The parent still delegates to the old servers. Resolvers reach the old provider, which may still be serving stale records or may return SERVFAIL.
You changed at the registrar but the child zone's NS records still list the old servers. Resolvers reach the right servers but cache the wrong authoritative set, and subsequent queries go astray.
Partial propagation during a transfer. Some resolvers hold the old delegation, others the new. Users report inconsistent behaviour depending on which resolver they use.
A nameserver in the list doesn't respond. Resolvers will retry across the set, so the domain still works — but every query pays a timeout penalty on the dead server first. This shows up as sporadic slowness rather than failure.
The lesson: NS records must be updated in both places, and the domain should be checked in both places after any change.
Glue Records
The special case that catches people out is nameservers within the domain they serve.
If example.com uses ns1.example.com as its nameserver, there's a circularity. To find example.com, a resolver needs ns1.example.com. To find ns1.example.com, it needs to query example.com. Which it can't reach yet.
Glue records break the loop. The parent zone publishes A/AAAA records for the nameserver hostnames alongside the delegation:
example.com. NS ns1.example.com.
ns1.example.com. A 192.0.2.10 ← glue
The resolver gets the address directly from the parent and can proceed.
Two failure modes:
Missing glue. The delegation exists, the nameserver is inside the domain, and no glue is published. The domain becomes unresolvable — a total outage that's completely invisible from inside your DNS provider's interface, because the problem is at the registry.
Stale glue. You change your nameserver's IP address in your own zone but not in the glue records at the registrar. Resolvers get the old address from the parent. This one is particularly nasty because your zone looks correct.
Glue is only needed for in-bailiwick nameservers — those inside the delegated domain. If you use ns1.provider.net to serve example.com, no glue is required, because ns1.provider.net is resolvable independently through the .net delegation.
Practical implication: using a third-party DNS provider's nameservers avoids glue entirely. Running your own nameservers under your own domain is where glue becomes something you have to maintain.
Serial Numbers and Zone Consistency
Every zone has an SOA record containing a serial number:
example.com. SOA ns1.provider.net. admin.provider.net. (
2026030901 ; serial
7200 ; refresh
3600 ; retry
1209600 ; expire
3600 ) ; minimum TTL
Secondary nameservers poll the primary, compare serials, and transfer the zone when the primary's serial is higher.
If all your nameservers report the same serial, they're in sync. If they differ, one hasn't received an update.
This is a genuinely useful check that few people run. Query the SOA record from each of your nameservers individually and compare the serials. A secondary stuck on an old serial will serve stale records to whichever resolvers happen to query it — which produces the "it works for me" pattern where the same domain resolves differently for different people.
The conventional serial format is YYYYMMDDNN — date plus a two-digit counter — which makes staleness immediately visible. A serial of 2025110402 on a zone you edited this morning tells you something is wrong.
The other SOA fields matter too:
- Refresh: how often secondaries check for updates
- Retry: how long to wait after a failed check
- Expire: how long a secondary keeps serving after losing contact with the primary
- Minimum TTL: the negative caching TTL — how long a NXDOMAIN response is cached
That last one is worth understanding. If you query a name that doesn't exist yet, the negative answer is cached for the minimum TTL. Create the record and it may not appear for that long, even though the record is published. Setting a very long minimum TTL makes new records slow to appear.
Nameserver Diversity
Publishing multiple nameservers is redundancy in principle. Whether it's redundancy in practice depends on what's actually different between them.
Four nameservers at the same provider, in the same datacentre, on the same network segment, sharing an authoritative database — that's four names for one point of failure.
Genuine diversity means variation in:
- Network — different ASNs and transit providers
- Geography — different regions
- Software — different DNS server implementations, so one bug doesn't affect all
- Organisation — different providers entirely
Full diversity across all four dimensions is complex to maintain and generally overkill for most sites. But knowing which dimension your redundancy actually covers is worth the five minutes it takes to check.
Most managed DNS providers use anycast, which gives geographic and network distribution within one provider. That covers a lot — a provider-wide outage is the remaining exposure, and secondary DNS at a second provider is the mitigation if that matters to you.
Changing Nameservers Safely
Nameserver changes transfer authority for your entire domain. A mistake takes everything down — website, email, everything.
The safe sequence:
1. Build the complete zone at the new provider first. Every record. Compare against the old zone record by record before touching anything.
2. Verify by querying the new nameservers directly. They'll answer for your domain even before delegation points at them.
3. Lower TTLs on critical records — particularly NS and MX — well ahead of the change.
4. Change nameservers at the registrar.
5. Watch both parent and child. Confirm the delegation has updated at the registry and that your zone's own NS records match.
6. Leave the old zone in place for at least a week. Resolvers with cached delegations continue reaching it, and if it's still serving correct records nobody notices the transition.
7. Verify from multiple resolvers and locations before considering it done.
The mistake that causes outages is deleting the old zone immediately after changing the delegation.
FAQ
Why do NS records exist in two places? The parent zone holds the delegation; the child zone holds its own authoritative statement. They should match, and a mismatch causes inconsistent resolution.
What are glue records? A/AAAA records published in the parent zone for nameservers that live inside the domain they serve, breaking the circular dependency.
Do I always need glue records? Only when your nameservers are subdomains of the domain they serve. Using a third-party provider's nameservers avoids the need entirely.
How do I check whether my nameservers are in sync? Query the SOA record from each nameserver individually and compare the serial numbers. Different serials mean one hasn't received an update.
Is four nameservers at one provider redundant? Partially. It covers individual server failure but not a provider-wide outage. Genuine redundancy varies network, geography, software or organisation.
How long does a nameserver change take? The registry update is usually quick, but resolvers cache the old delegation for its TTL. Leave the old zone running for at least a week.
The Takeaway
Nameserver problems are usually consistency problems: the parent and child disagree, the glue is stale, or one secondary is serving an old zone. All three are invisible from a DNS control panel and all three are quick to check — compare the two NS record sets, verify the glue, and confirm the SOA serials match across every nameserver you publish.
Find the authoritative nameservers for any domain free with the NS Lookup at sadiqbd.com — no sign-up, instant results.
