Delegation: the one concept that explains most DNS outages
NS records exist in two places at once, and understanding that duplication resolves most confusing DNS behaviour. The parent zone (.org for wikipedia.org) publishes NS records that delegate the child zone to a set of servers. The child zone publishes its own NS records at its apex. Resolvers follow the parent's delegation to find the servers; the child's copy is what you normally see in a lookup.
dig +noall +answer wikipedia.org NS
wikipedia.org. 10061 IN NS ns2.wikimedia.org.
wikipedia.org. 10061 IN NS ns0.wikimedia.org.
wikipedia.org. 10061 IN NS ns1.wikimedia.org.When the two copies disagree, you get a "lame delegation": the parent sends resolvers to a server that does not consider itself authoritative for the zone, or that no longer has the zone at all. Symptoms are intermittent — some resolvers happen to pick a working server, others do not — and they survive every cache flush, because nothing is cached wrongly. The delegation itself is wrong.
How to read the results
- Two or more nameservers is the minimum every registry requires, and for good reason: one nameserver is one outage away from your entire domain disappearing, mail included.
- Nameservers in different networks is what real redundancy looks like. Two names on the same provider in the same datacentre share a failure domain — check with an ASN lookup whether they are genuinely separate.
- Nameservers inside the zone they serve (
ns1.example.comservingexample.com) require glue records at the registrar — A records stored in the parent zone to break the circular dependency. If the glue is missing or stale, the domain fails to resolve from cold caches while continuing to work from warm ones. - A nameserver name that does not resolve is a hard failure waiting to happen. Every name listed here should have working A (and ideally AAAA) records.
- An empty result at a name below the apex simply means that name is not a delegation point. Query the registrable domain instead.
Read the full explanation of ns record lookup results ↓Show less ↑
Changing nameservers without downtime
- Copy the entire zone to the new provider first, record for record. Missing MX or TXT records is how nameserver migrations break mail rather than the website — the part nobody tests before cutting over.
- Verify the new servers answer authoritatively before touching the registrar:
dig @new-ns1.provider.com example.com SOAshould return an answer with theaaflag set, not a referral. - Lower the TTLs inside the zone (not the NS TTL, which the parent controls) a day ahead, so records can be corrected quickly after the switch.
- Change the nameservers at the registrar. This edits the parent delegation, which is what actually matters. Editing NS records inside the old zone does nothing useful.
- Keep the old nameservers serving the old zone for at least 48–72 hours. Resolvers that cached the old delegation will keep asking them, and if they start returning NXDOMAIN or REFUSED you get exactly the outage you were trying to avoid.
- Confirm the change with this tool and with the DNS propagation checker across many networks before decommissioning anything.
Common failures and fixes
- Domain resolves for you but not for others. Classic lame delegation or partially updated glue. Compare what the parent says with what the zone says using the commands below.
- SERVFAIL from every resolver. Either all listed nameservers are unreachable, or the zone is signed and failing DNSSEC validation. Rule out the second with the DNSSEC checker — a nameserver change that drops DS records or breaks signing produces SERVFAIL, not NXDOMAIN.
- Nameservers still show the old provider days later. The registrar change may not have been applied; some registrars require a separate confirmation, and a domain on clientUpdateProhibited will silently refuse edits. Check the registrar record with WHOIS.
- Mail broke after the nameserver change but the site is fine. The MX and TXT records were not copied to the new provider. Verify with the MX lookup and the SPF checker.
- A nameserver was renumbered but the glue was not updated. Cold resolvers fail while warm ones succeed. Update glue at the registrar, then wait out the parent's TTL.
Checking the parent and the child separately
This is the diagnostic that separates a real delegation problem from a caching artefact. Ask the parent what it delegates to, then ask the zone what it claims for itself, and compare:
# What the zone itself publishes (the child copy)
dig +short wikipedia.org NS
# What the parent zone delegates to — ask a TLD server directly
dig +noall +authority @a.gtld-servers.net example.com NS
# Walk the delegation from the root and watch each hand-off
dig +trace example.org NS
# Confirm a specific server is authoritative (look for the "aa" flag)
dig @ns0.wikimedia.org wikipedia.org SOA | grep -E 'flags:|status:'If the parent lists servers the child does not, or the child lists servers the parent has never heard of, you have found your problem. Both sets should match, every listed server should answer authoritatively, and every server name should resolve.