Understanding Nameservers: Delegation, Glue and Changes

Nameservers are the servers that hold the official DNS records for a domain. When someone looks up your website or sends you email, their resolver eventually asks one of your nameservers for the answer. Which nameservers those are is decided by a delegation recorded at the registry for your TLD, which is why changing DNS providers means updating settings at your registrar, not just in a DNS control panel.

Delegation: how the parent points to you

DNS is organized as a tree of zones. The root zone delegates .com to the .com registry's servers, the .com zone delegates example.com to whatever nameservers the domain holder has chosen, and so on. A delegation is simply a set of NS records in the parent zone:

example.com.   172800   IN   NS   ns1.example.net.
example.com.   172800   IN   NS   ns2.example.org.

When a resolver asks a .com server about www.example.com, it gets these NS records back as a referral and then asks ns1.example.net or ns2.example.org directly. The walk from root to answer is described in How DNS works.

Your own zone should also publish NS records at its apex, and those should list the same servers as the parent. The parent's copy is what gets resolvers to you; the child's copy is what your servers say about themselves. When the two sets differ, resolvers may behave inconsistently.

You set the parent's NS records through your registrar, which passes them to the registry. You set the child's NS records in your DNS provider's zone.

Glue records

Delegation has a chicken-and-egg problem. Suppose example.com uses ns1.example.com and ns2.example.com as its nameservers. To find the address of ns1.example.com, a resolver would need to ask example.com's nameservers, which it cannot reach without first knowing that address.

Glue records break the loop. They are A and AAAA records for the nameservers, published in the parent zone alongside the delegation:

example.com.       172800   IN   NS     ns1.example.com.
example.com.       172800   IN   NS     ns2.example.com.
ns1.example.com.   172800   IN   A      192.0.2.53
ns2.example.com.   172800   IN   A      198.51.100.53

Glue is only needed when a nameserver's name is inside the zone it serves, or inside a zone that depends on it. If your nameservers are ns1.example.net for a domain called example.com, no glue is needed, because the resolver can look up example.net separately.

At most registrars, you create glue by registering "child nameservers" or "host records" with their IP addresses. If you change the IP address of such a nameserver, remember to update the glue at the registry as well; forgetting to do so is a common cause of hard-to-trace outages.

Why at least two, on different networks

The DNS standards have long called for at least two nameservers for every zone, and most registries enforce a minimum of two. The goal is resilience: if one server is unreachable, resolvers try another.

Two servers only help if they do not fail together. Guidance in RFC 2182 recommends placing secondary servers so they do not share single points of failure. In practice:

• Different networks. Servers on the same subnet, or behind the same router or upstream provider, can all disappear at once.
• Different locations. Separate data centers or regions protect against local power or connectivity problems.
• Consider a second provider. Some organizations use two independent DNS providers, which requires keeping both zones in sync, either through zone transfers or automation.

Many managed DNS services use anycast, where one nameserver address is announced from many locations. That provides considerable redundancy behind a single name, but it is still worth understanding what would happen if that one provider had a problem.

Changing nameservers safely

Moving to a new DNS provider is routine, but a careless switch can take a site or mailbox offline. A safe sequence:

1. Recreate the full zone at the new provider first. Copy every record, including MX, TXT (SPF, DKIM, DMARC, verification tokens), CNAMEs and anything on subdomains. Missing TXT records often go unnoticed until email starts failing.
2. Verify the new servers directly. Query the new nameservers by name and confirm they return the right answers before anything points to them.
3. Deal with DNSSEC. If the domain is signed, either remove the DS record at the registrar and wait for it to expire from caches before switching, or arrange a coordinated key rollover between the old and new providers. Leaving an old DS record in place after moving to an unsigned or differently signed provider will make the domain fail for validating resolvers. See What is DNSSEC?.
4. Update the nameservers at your registrar.
5. Keep the old provider running for a while. The parent's NS records have their own TTL, often a day or two for large TLDs, and resolvers will keep asking the old servers until their cached delegation expires. Leave the old zone intact and unchanged for at least that long.
6. Update the apex NS records in the new zone so they match the delegation.

Lame delegation and other common faults

Lame delegation

A delegation is called lame when the parent lists a nameserver that does not answer authoritatively for the zone. The server might not exist, might not respond, or might respond but not have the zone configured. This often happens when a domain has moved providers and the old nameserver is still listed, or when a provider deletes a zone without the delegation being updated.

Resolvers work around a lame server by trying the others, but each failed attempt adds delay, and if every listed server is lame the domain stops resolving entirely.

Other issues to watch for

• Parent and child NS sets disagree, so behavior depends on which set a resolver trusts.
• Nameservers disagree with each other, often because zone transfers to secondaries have stopped and their SOA serial numbers no longer match.
• Nameserver names with no address records, or names that are CNAMEs, which the standards do not allow for NS targets.
• All nameservers in one place, which works until the day that network has a problem.

Check it yourself

• Nameserver Checker compares the delegation at the parent with the NS records in your zone, queries each nameserver directly, and flags lame servers, SOA serial mismatches and missing glue.
• DNS Lookup lets you check NS, SOA and address records for a domain or for the nameservers themselves.