Nameservers and NS records

An NS record names a server that is authoritative for a zone. It answers the question “who holds the official records for this domain?”

Two copies of the same information

The NS set is published in two places.

The parent zone publishes the delegation. For example.com, the .com zone tells resolvers which nameservers to ask.

The child zone also publishes an NS set at its own apex. In a healthy setup both copies agree. When they don’t, different queries show different servers and debugging gets confusing fast.

One more thing to keep straight. A nameserver is a DNS service. It’s not the machine that serves your website or receives your email.

Glue

Sometimes a nameserver’s own name lives inside the zone it serves. The nameserver for example.com is ns1.example.com. To reach it you need its address, and to get its address you’d ask… ns1.example.com.

The parent breaks this loop with glue records: the IP addresses of those nameservers, stored alongside the delegation.

Changing nameservers moves authority

When you change nameservers you move control of the whole zone. Every record moves with it. So prepare the destination first, then flip:

1. Recreate the complete zone at the new DNS host and check every record.
2. Copy the exact nameserver names the new host assigned you into the registrar’s settings.
3. Keep the old zone alive while parent and resolver caches expire.
4. Query the new authoritative servers directly before you call it done.

Be careful with step 2. The registrar updates the parent delegation. Adding an NS record inside your old zone’s editor does not move the domain anywhere. It’s a different setting in a different place.

Inspect the delegation

Let’s look at what the public sees:

dig NS example.com +short
dig +trace example.com NS

The first is what your resolver has cached. The trace shows what the parent hands out.

Now take one of those servers and ask it directly:

authoritative_server=$(dig NS flaviocopes.com +short | head -n 1)
dig @"$authoritative_server" flaviocopes.com SOA +norecurse

+norecurse tells the server not to go looking elsewhere. If it’s authoritative you’ll see the aa flag in the response.

Try this: write down the nameservers from the plain query and from the trace. If they differ, work out which one you’re looking at: a cache, the parent delegation, or the child zone’s own data.