How to Find Where Your Domain's Nameservers Actually Point

To check nameservers for a domain, query the delegation records that its parent zone publishes, then compare the answer against the records the zone itself serves. The first tells you which servers the rest of the internet believes are authoritative; the second tells you what those servers actually say. When the two disagree, you are looking at a delegation change that has not finished propagating, and that state explains most of the confusing symptoms people report.

What a nameserver check actually asks

DNS resolution starts above your domain. The root zone delegates a top level domain to a set of servers, those servers hold a zone file that contains a delegation for your domain, and that delegation is a pair of records: NS records naming the authoritative servers, and usually glue A and AAAA records giving their addresses. A resolver that wants to look up something under your domain walks down that chain and stops when it reaches the servers named in the delegation.

That is the distinction that matters. The NS records in the parent zone are the delegation. The NS records at the apex of your own zone are your intent. Registrars write the first; your DNS provider writes the second. Nothing enforces that they match, and in practice they often do not for a while after a change.

Propagation is not a single event. It is the time it takes for caches that already hold the old answer to expire, bounded by the TTL on the old records, plus the time it takes for the parent zone to publish the new delegation. Those are different clocks and they are not synchronised. A parent zone change can be nearly instant while resolvers around the world keep serving the old set for hours, or the reverse if the registry is slow to accept the update.

How to check nameservers for a domain at the delegation level

Ask a resolver that is not your own and that you do not control. The simplest approach is a query for NS records with recursion disabled, so you see cache contents rather than a fresh walk, and then again with recursion enabled, so you see what a normal client would get.

dig +norecurse NS example.com @a.gtld-servers.net
dig NS example.com @1.1.1.1
dig NS example.com @8.8.8.8

Read the ANSWER section, but read the AUTHORITY section too, because that is where the delegation lives. A response from a top level server typically has an empty ANSWER and a populated AUTHORITY section containing the NS records, with the aa flag unset. That is not an error. It means the server is pointing you downward rather than answering for the zone.

;; AUTHORITY SECTION:
example.com.  172800  IN  NS  ns1.provider.example.
example.com.  172800  IN  NS  ns2.provider.example.

;; ADDITIONAL SECTION:
ns1.provider.example.  172800  IN  A  192.0.2.1

Those ADDITIONAL records are glue, and they exist because the nameservers live inside a zone that would otherwise require a lookup that depends on the answer itself. If the glue is stale or missing, resolvers cannot reach the servers even though the delegation looks correct on paper. Querying the addresses directly is worth doing when a domain resolves for some people and not others.

dig NS example.com @192.0.2.1
dig SOA example.com @192.0.2.1

A response with the aa flag set from that address means the server genuinely holds the zone. A REFUSED or an empty answer with no aa flag means it does not, and the delegation is pointing at a server that will not answer for the name.

Reading the header and spotting the failure modes

The header flags carry most of the diagnostic information. The aa bit means authoritative. The ra bit means the responder offers recursion, and if you sent +norecurse the rd bit should be clear. A SERVFAIL status usually means the server tried to resolve something and could not, which often points at broken glue or a lame delegation. NXDOMAIN from an authoritative server means the name does not exist in that zone, which is a different problem from a delegation that never arrived.

The three common failures look like this. A lame delegation is when the parent names a server that does not hold the zone, so every query to it returns REFUSED or a referral back upward. A missing delegation is when the parent has no NS records at all, so the query dies at the top level server. A mismatched set is when the parent and the apex name different servers, which works fine until one of the two stops answering.

If you have shell access to the machine that serves your zone, compare what is configured against what is published. The configuration format depends on the software, but the shape is always the same: a zone block naming the origin, and either a list of nameservers or a set of NS records in the zone file itself.

zone "example.com" {
    type master;
    file "/etc/bind/zones/db.example.com";
};

; inside db.example.com
@   IN  NS  ns1.provider.example.
@   IN  NS  ns2.provider.example.

On a managed provider the equivalent is a control panel field, and the value you paste there is what ends up in the apex records. That field does not touch the parent zone. Only the registrar can change the delegation, which is why a change made in a DNS panel can appear to do nothing at all.

Changing nameservers without breaking mail or the site

Lower the TTL on the records you are about to move, well before you move them. If your MX records point at names like mail.example.com that live inside the zone, the mail flow depends on the zone resolving, not just on the MX target. Moving to a new provider without recreating those names breaks delivery even though the MX records themselves were never touched.

Recreate the zone at the new provider first, verify it answers correctly by querying its servers directly, and only then change the delegation at the registrar. Doing it in that order means the new servers are already serving the full zone when the parent starts pointing at them. Doing it in the other order creates a window where the delegation names servers that have nothing to serve.

Watch for two things after the switch. First, the parent zone and the apex will disagree for a period, and that is expected. Second, anything that referenced a nameserver by name, such as a secondary zone transfer or a monitoring check pinned to a specific host, needs updating too. Transfers use AXFR and depend on the primary's address, which may not change even when the delegation does.

What to do next

Run the delegation query against a top level server and the authoritative query against each nameserver address in turn, and keep the output. That pair of answers is the baseline you will compare against the next time something resolves for one person and not another. If the two disagree, wait for the old TTL to lapse before changing anything else, because a second change on top of an unfinished one makes the timeline impossible to read. And before you touch the registrar, confirm that the new zone already answers correctly for the records that carry your mail, not just the ones that carry your website.