Free tool
Which nameservers answer for this domain?
A domain's nameservers, and the comparison nobody makes by hand: what the zone answers, against what the registry actually delegated. No sign-up, no email to leave.
They decide everything else
A domain's nameservers are the authority behind every other answer — where the site lives, where mail goes, which certificate gets validated. Change that list, or get it wrong, and it is not one page that breaks. The whole domain moves at once, site and mail together, usually without anyone deciding it should.
Two sources, and they do not always agree
The domain's registry publishes a delegation. The servers it names publish a list of their own. The two should match. When they drift apart, resolution turns into a lottery — depending on which resolver a visitor uses, they land on the old hosting or the new one. The tool asks both sources and shows you the gap.
The descent
Three questions put to three different servers
Nobody holds the whole answer. Each server points to the next, until you reach the one that is authoritative for your domain. Step through the conversation.
The resolverWho can answer for www.example.com?
Root serverI only know the extensions. For anything ending in .com, ask the .com servers.
An authoritative answer comes from the server the registry designates. Everything before it is just a referral to the next one.
The rule most often broken
Two. That is the minimum, and it is not advice.
2servers
A domain served by a single machine is a domain with a single point of failure.
The two-nameserver minimum has sat in the system's foundations since RFC 1034 (1987) and has never moved. RFC 2182 goes further and recommends putting them on separate networks, ideally with two operators, so that one outage is not the domain's outage — site, mail and certificates included.
Reading the result
The table lists the servers the zone itself announces. The findings below hold that list up against the registry's delegation, then check that every server named leads to a real address.
- All clear — both lists match
- The registry delegates to the same servers the zone announces, and every one of them resolves. This is what a healthy domain looks like.
- Worth watching — registry and zone diverge
- The two lists do not match. Mid-migration that is normal, until the old delegation clears out of everyone's memory. After a few days it is an oversight, and it leaves a slice of your visitors on the old site.
- Worth watching — a single nameserver
- The entire domain rests on one machine. The standard has asked for two since day one, and for good reason — when that machine goes, the site and the mail go with it, and nothing picks up.
- Problem — a nameserver does not resolve
- The name is in the list but leads to no address. Any query that lands on it gets nothing back, and resolution turns intermittent — the failure people describe as: it works one time in three.
- Problem — no nameserver at all
- The zone declares none at all. Nothing resolves for this domain now — not the site, not the mail, not the certificates.
- Problem — the name does not exist
- No nameserver knows this domain. It was never registered, it no longer is, or its delegation was pulled.
- Undetermined — servers inside the domain
- The servers named carry a name inside the domain they serve, so their address can only come from the registry, in what is called a glue record. Not a fault — one more dependency, and one an ordinary resolver has no way to verify.
- Undetermined — no answer in time
- The resolver came back with nothing in time. That happens on a slow zone, or one that is briefly overloaded.
The mistakes we see most often
The servers were changed at the registrar, the zone was never copied over
What causes it: someone points the delegation at a new provider before recreating the records there. The new server answers that it knows nothing about the domain, or serves an empty zone.
What fixes it: build the full zone at the new provider, query that provider directly to confirm it, and change the delegation only then.
The old provider was left in the list
What causes it: the two new servers go in and the two old ones never come out. Resolvers hit one or the other at random, so the site comes back new for some people and old for others.
What fixes it: a delegation holds the servers of ONE provider. Take the old ones out on switch day.
The domain was signed, and the signature stayed at the registry
What causes it: a domain protected by DNSSEC keeps a fingerprint of its zone key at its registry. Switch provider without removing it and resolvers that verify signatures stop finding a match, so they refuse every answer. The domain vanishes for part of the internet and stays perfectly fine for the rest.
What fixes it: remove the fingerprint at the registrar BEFORE changing the delegation, or publish a matching key at the new provider.
The lifetime was not lowered before the change
What causes it: nameservers stay cached a long time, often a day or two. While the old answer is still alive, part of the world keeps querying the old provider.
What fixes it: lower the lifetime a few days before the switch, and put it back up once the change is visible everywhere.
The two servers are two names on the same machine
What causes it: two different names aimed at the same address look like redundancy without being it. One machine failure takes both out.
What fixes it: check that the servers announced resolve to different addresses. That is the whole point of the two-server rule.
Who holds what, when a name is resolved
Most delegation failures come down to confusing these five. Each one holds a piece of the answer, and there is no sense fixing in one place what another place publishes.
| Actor | What it holds | What gets fixed there |
|---|---|---|
| The registry | The delegation — the official list of the domain's nameservers, plus the address of any server whose name sits inside the domain. | Changing DNS provider, and the DNSSEC fingerprint. Nothing else. |
| The registrar | Technically nothing. It is the middleman you go through to ask the registry to change the delegation. | The panel where nameservers are entered, renewal, the transfer lock. |
| The authoritative servers | The zone — every record the domain has, addresses, MX, TXT, aliases, and the nameserver list as the zone declares it. | All the domain's content. This is where an MX or a TXT is added. |
| The recursive resolver | Nothing of its own. It queries the others and holds their answers for as long as they said to. | Nothing. You do not fix a resolver, you wait for its memory to expire. |
| The glue record | The address of a nameserver whose name sits inside the domain it serves. | At the registry, through the registrar. Without it, resolution runs in circles. |
The rule of at least two nameservers goes back to the foundations of the system (RFC 1034), and the recommendation to put them on separate networks comes from RFC 2182.
What a nameserver's answers mean
Every DNS answer carries a code. A browser never shows it, but it is what separates a name that does not exist from a server that refuses to answer — two failures with nothing in common.
| Code | What the server is saying | What to look at |
|---|---|---|
| NOERROR | The question succeeded. | If no data comes with the answer, the name exists but carries no record of that type. |
| NXDOMAIN | This name does not exist. | A typo, a deleted record, or an expired domain. |
| SERVFAIL | The server could not produce an answer. | On a signed domain, the usual cause is a DNSSEC signature that no longer matches the fingerprint published at the registry. |
| REFUSED | The server refuses to answer for this zone. | It does not consider itself responsible for the domain. The delegation points at a server that does not host the zone. |
| NOTIMP | The server does not know how to handle this question. | Rare, and unrelated to the domain's contents. |
| FORMERR | The question was malformed. | A problem with the sender or with network equipment rewriting packets, not with the zone. |
These codes come from the DNS standard (RFC 1035) and have been extended since. The same domain can return NOERROR on one resolver and SERVFAIL on another, because only resolvers that verify signatures ever see a DNSSEC error.
Common questions
What is a nameserver?
It is the machine holding the authoritative answer to every question about a domain — which address for the site, which servers for the mail, which verification records. Change nameservers and you change authority for the whole domain, not just for the site.
How do I know my nameserver change has gone through?
Compare two sources. The registry publishes the official delegation, and the servers it names publish a list of their own. As long as those differ, the change is not finished — which is exactly the comparison the tool above runs.
How many nameservers do I need?
Two, minimum, and that comes from the system's founding rules, not from an administrator's caution. Two distinct addresses, ideally on different networks — redundancy built from two names aimed at one machine protects against nothing.
How long does a nameserver change take to propagate?
The registry publishes the new delegation within minutes or hours. What takes time is the memory of resolvers around the world. They hold the old answer for as long as it announced, often one to two days, and during that window both hostings answer.
What is a glue record?
When a domain's nameservers carry a name inside that same domain, you cannot resolve them without already knowing how to reach them. So the registry publishes their address directly, next to the delegation. That is the glue. It does not exist when the servers belong to another domain.
My site went down after a nameserver change, but the zone is correct
If the domain was protected by DNSSEC, the old key's fingerprint is probably still sitting at the registry. Resolvers that verify signatures stop finding a match and refuse every answer, while the rest serve the site normally. This is the outage that only hits some people.
How do I look up nameservers with dig or nslookup?
On macOS and Linux, dig NS example.com +short returns the list the zone announces. On Windows, nslookup -type=ns example.com gives you the same thing with nothing to install. To see the delegation the registry publishes rather than the zone's own list, dig +trace NS example.com walks the whole path down from the root.
Can I change nameservers without downtime?
Yes, as long as you recreate the complete zone at the new provider before touching the delegation, lower the record lifetime several days ahead, and remove the DNSSEC fingerprint if the domain is signed. Downtime never comes from the switch itself. It comes from a record forgotten in the new zone, and that record is almost always an MX.
A hosting migration, hour by hour
Nothing here is exceptional. Every step is the system behaving exactly as designed, and not one of them is a fault. What costs you the day is that the symptoms never arrive in the order of their causes.
09:00
The new name servers are entered at the registrar
What you seeThe interface confirms the change. The site responds, mail arrives, everything looks fine.
What is happeningNothing has moved for anybody. The registry has recorded the new delegation, but every resolver in the world holds the previous answer until the lifetime it announced runs out — for a delegation, often one to two days.
09:40
The new version of the site appears from the office
What you seeYou refresh, the new page shows up. The migration is declared done.
What is happeningYour office resolver simply forgot the old answer before everyone else's did. A colleague on another network still sees the old site, and may still see it tomorrow. One machine proves nothing.
11:15
A client replies to a quote, and the message never arrives
What you seeNo bounce, no alert. The inbox is just empty, and it takes until the afternoon to notice.
What is happeningThe MX records were never recreated in the new zone. Resolvers that have already moved to the new provider find no mail server, and the sender's server queues the message without saying a word. The silence outlasts the outage by a long way.
14:00
The MX records are recreated in a hurry
What you seeMail starts arriving again within the hour, often in bursts.
What is happeningAlmost nothing is lost. A server that cannot deliver keeps retrying for days before it gives up, and the standard tells it to wait at least four to five days. What you lose is the half day nobody got an answer.
Day 2, 10:00
Some visitors still see the old site
What you seeThe site is live, the zone is correct, and screenshots of the old version keep coming in.
What is happeningThe previous provider's servers were left in the delegation next to the new ones. Both answer, each resolver picks one, and it sticks with that choice until its memory expires. Your site now comes back in two versions depending on the visitor's network.
Day 3
For some people the domain no longer exists at all
What you seeNeither the old site nor the new one. A resolution error, and only for part of your audience.
What is happeningThe domain was signed. The fingerprint of the old key is still published at the registry, and resolvers that verify signatures now refuse to answer at all rather than serve something they cannot authenticate. The rest see nothing wrong, which is why this outage gets described as hitting only some people.
Not one of these six steps is a malfunction. DNS is doing precisely what it was told. Only the order of the actions changes the outcome, and that order fits in nine lines.
The delay before a server gives up on a queued message is the one recommended by RFC 5321, § 4.5.4.1. The names used here are those RFC 2606 reserves for documentation.
Changing name servers without cutting off your mail
Nine actions, three phases. Half the work happens before you touch the delegation at all, and that is the half people skip.
Several days before
Export the whole zone
Take the complete list off your current provider — addresses, MX, TXT, aliases, the subdomains everyone forgot. It is always the lines nobody remembered that break.
Lower the record lifetime
Bring it down to a few minutes in the old zone. Do it a full lifetime ahead, or the lowering itself takes two days to be noticed.
Check whether the domain is signed
If it carries a DNSSEC fingerprint at its registry, remove it and wait for it to clear. This one has no fix after the fact — the domain goes invisible to part of the internet, and never to you.
On switchover day
Recreate the zone before delegating
Put everything back at the new provider, MX and TXT included, while nobody is querying it yet.
Query the new servers directly
Ask them without going through the delegation. If they already answer with the right zone, the switch just points traffic at something that is already correct.
Replace the delegation, do not extend it
Pull the old servers at the same moment you add the new ones. A mixed delegation leaves two different zones answering, and each resolver decides which.
In the days that follow
Compare both sources until they agree
The registry and the zone must announce the same list. As long as the tool at the top of this page shows a gap, the migration is not finished.
Raise the lifetime again
Once everything is stable, put it back to its usual value. A short lifetime left in place multiplies queries for nothing.
Only close the old hosting afterwards
As long as it still answers, a mistake stays fixable in a minute.
The four things that change nothing
Clearing the browser cache
It does hold a few minutes of DNS answers, but the one blocking you sits in your provider's resolver, out of your reach.
Asking the host to force propagation
Nobody can clear the memory of every resolver in the world. Only the lifetime announced before the change decides how long it takes.
Reloading all day from the same machine
Your resolver has already picked its answer and is sticking with it. A check that queries several resolvers tells you something. Your browser tells you nothing.
Leaving the old server in just in case
That is precisely what produces a site answering in two versions depending on who is asking.
Asking the same questions yourself, on the command line
The tool at the top of this page runs these queries for you and compares both sources. If you would rather run them yourself, or check from a client's network, here is exactly what to type.
macOS, Linux
dig NS example.com +shortWhat the zone announces
What to read: the list of name servers as published by the current DNS provider. This is the left half of the comparison, the one that changes as soon as the new zone is in place.
macOS, Linux
dig +trace NS example.comWhat the registry delegated
What to read: the query restarts from the root and follows the whole path down. The block just before the final answer comes from the TLD servers, and that is the official delegation — the one that has to match the previous list. Some corporate networks block this mode, and the command then stops at the first line.
Windows
nslookup -type=ns example.comThe same question, with nothing to install
What to read: nslookup ships with Windows. It queries your network's resolver, so it shows what your machine sees, not necessarily what the rest of the world sees.
macOS, Linux
dig SOA example.com +shortWhether the zone really changed
What to read: the third element of the answer is the zone serial number, and it goes up with every published change. If it has not moved after you saved, your change never left. The last number is how long an answer saying this name does not exist stays in memory.
macOS, Linux, Windows
whois example.comThe delegation as the registry sees it
What to read: the Name Server lines come from the TLD registry, not from the zone. Extensions do not all publish the same fields, and several registries cap how many queries one address can make per day.
dig ships with macOS and comes from the bind-utils or dnsutils packages on Linux; on Windows, nslookup does the same job. The names used here are the ones RFC 2606 reserves for documentation: replace them with your own.
What this check cannot see
It queries DNS from one place in the world, at one instant. Knowing its blind spots keeps you from drawing a conclusion it does not support.
It looks from a single network
The list shown is what our servers got back just now. A resolver elsewhere may keep serving an older answer for the whole lifetime it announced. A gap between this page and what you see at home is not a contradiction. It is what a change in progress looks like.
It does not verify signatures
The check says nothing about whether the domain is protected by DNSSEC, or whether the fingerprint published at its registry still matches its key. And that is the cause behind the most baffling outage after a provider change, the one that only hits some visitors.
It cannot see the glue
When nameservers carry a name inside the domain they serve, the registry publishes their address rather than the zone. An ordinary resolver cannot read it, so this page can flag the situation but not check what is in it.
It does not test the whole list
Only the first four servers listed get their resolution checked. On a delegation of six, the last ones are shown without being tested.
It says nothing about the zone's contents
Knowing who is authoritative tells you nothing about whether the zone is complete. A new delegation can be perfectly correct and point at an empty zone — which is exactly the 11:15 step above.
It does not go back in time
No history. The page gives you this instant and nothing else. To catch a delegation that changed overnight you have to look every day, and that is monitoring, not a one-off check.
These limits follow from what a recursive resolver is, as described in RFC 1034. It only sees what the servers it queries agree to return, and never what the registry publishes alongside the delegation.
The vocabulary
Eight words to know who answers what
These are the words in your registrar's interface, in what dig hands back, and in the table above.
delegation- The official list of a domain's name servers, held by the extension's registry.
authoritative- A server that holds the zone itself and answers with no cache in between.
zone- What the domain contains — addresses,
MX,TXT, aliases, and the server list as the zone publishes it. glue- The address of a name server whose name sits inside the domain it serves. Without it, resolution goes in circles.
registry- The extension's organization (.fr, .com). It holds the delegation and the
DNSSECfingerprint, nothing else. registrar- The middleman you go through to ask the registry to change the delegation. Technically it holds nothing.
recursive resolver- The server that queries the others on your machine's behalf and keeps their answers for as long as it was told to.
SERVFAIL- The server could not produce an answer. On a signed domain, the first suspect is a
DNSSECsignature that no longer matches.
A registrar hosts nothing. It forwards.