NS Records and Delegation

One list, published twice

An NS record names a nameserver that is authoritative for a zone. Every other record type lives in one place; the NS records for your domain are published twice, by two different parties, and only one of those copies is authoritative.

One copy sits in the parent zone. When you set nameservers at your registrar, the registrar passes that list to the registry that runs your extension, and the registry publishes it as the delegation for your domain. This is the copy the world meets first. RFC 1034 is blunt about its status: the NS records that describe a cut are not part of the authoritative data of the parent zone, and they should be exactly the same as the corresponding records at the top of the subzone.

The other copy sits in your own zone, at its apex - the top of the zone, where the SOA record also lives. That set is authoritative. RFC 2181 assigns the apex NS records to the child zone rather than to the parent, so when a resolver asks one of your servers directly, the answer it gets outranks the referral that sent it there.

Nothing in the protocol forces the two to match. They agree because someone keeps them in agreement, and the rest of this guide is what happens when nobody does.

What the registrar submits, and what it does not

Setting nameservers at your registrar is a registry operation rather than a DNS edit. The registrar writes the new delegation into the registry's database, the registry publishes it in the extension's zone, and a resolver asking about your domain is sent somewhere new.

Three things that change does not do:

• It does not move your records. A, AAAA, MX, TXT and CAA records do not travel with the delegation. Point a domain at a provider where the zone has not been built and the site and the mail go down as resolvers pick up the change.
• It does not change your registrar, your registrant details, or the expiry date.
• It does not take effect at a moment you choose. Resolvers holding the old delegation keep using it until that cached copy ages out, and the TTL on a delegation is set by the registry rather than by you.

A WHOIS or RDAP lookup shows the parent's view: the nameservers the registry has on record, published under ICANN's Registration Data Policy even where registrant details are redacted. What the lookup cannot tell you is what your own zone says, or whether the servers named in it are answering at all.

The set your own zone publishes

Your zone's apex NS set is usually not something you wrote. Managed DNS providers create it with the zone, fill it with the servers they assigned you, and treat it as infrastructure. One large provider creates the apex NS and SOA records automatically and blocks their deletion through its API; another advises against adding, changing or deleting servers in that record except in rare circumstances.

That advice is worth taking, because the apex set is one half of a pair. Editing it by hand, or leaving it behind after a migration, is the most common way the two halves drift apart. The usual sequence: a zone is copied to a new provider, the delegation is updated at the registrar, and the copied zone still carries the old provider's nameservers at its apex. Two sets of servers now answer, and they disagree about who is authoritative.

There is a legitimate case for an apex set larger than one provider's list. Running two DNS providers for redundancy means both providers' servers appear in the delegation and in the zone at each provider, deliberately and kept in step. Arriving at the same shape by accident is a different matter.

Glue, and the minority who need it

A glue record is an address record published by the parent alongside the delegation, and it exists to break a circle. If example.com is served by ns1.example.com, a resolver must find that server's address before it can ask anything, and finding the address means asking example.com, which means asking the server it cannot yet reach. The parent breaks the loop by publishing the address itself.

The condition is narrow, and RFC 1034 states it exactly: glue records are only necessary if the nameserver's name is below the cut. RFC 8499 supplies the vocabulary - a nameserver named inside the zone it serves is in-bailiwick, one named outside it is out-of-bailiwick. Nameservers on a managed DNS provider are almost always named under the provider's own domain, which is out-of-bailiwick, resolvable on its own, and needs no glue at all.

Glue matters for vanity nameservers and self-hosted ones. Those addresses are registered through your registrar as host records held at the registry, not in your zone file, which makes them easy to forget: change the address of a nameserver named inside your own domain and you have to change it in two places, one of which is not in your DNS panel. RFC 2181 ranks glue below authoritative answers, so a resolver that reaches the server replaces stale glue with what the server says - but one that cannot reach it, because the glue was wrong, never gets that far.

What a lame delegation actually is

A lame delegation exists when a nameserver is delegated responsibility for a zone through NS records but is not providing service for that zone, usually because it was never set up as a primary or secondary for it. That is the definition in RFC 8499 and, before it, in RFC 1912. Note what it describes: a listed server that does not serve. It is a property of one server in the set.

Two conditions are routinely called lame delegation and are not:

• A mismatch between the parent's list and your zone's list. That is an inconsistent delegation. It often produces lameness, but a delegation can be inconsistent while every server listed on both sides answers correctly.
• Any failure at the registry or registrar level, such as an expired domain, a hold status, or a DNSSEC validation failure. Those are separate faults with separate fixes.

Lameness is unpleasant to diagnose because a delegation lists several servers and a resolver asks one of them. Which one depends on the implementation, on what it has cached, and on recent performance. If three servers in your delegation serve the zone and one does not, the domain works for most people most of the time and fails for the rest without pattern. The user who reports the outage cannot reproduce it an hour later, and nothing looks wrong when you check, because your own resolver holds an answer from a server that works.

Adding a server is reversible; removing one is not

Adding a nameserver to a delegation is a low-risk change. Resolvers holding the old list keep using servers that work; resolvers that pick up the new list gain one more working option. Nothing that was reachable becomes unreachable.

Removing one inverts that. The moment a server leaves the delegation, every resolver that cached the old list is still pointing at it, and if you have also stopped serving the zone there, all of them are querying a lame server. RFC 1912 gives the instruction directly: to prevent lame delegations while the cache ages, keep providing nameservice on the old nameserver for the maximum of the minimum plus refresh times of your zone and of the parent zone.

The order matters more than the timing.

• Build the zone at the new provider and check it record by record against the old one before touching the delegation.
• Change the delegation, and leave the old provider's zone serving correct answers.
• Wait out the cached delegation, which is governed by TTLs at the registry and on the old servers rather than by any fixed propagation period.
• Only then delete the zone at the old provider.

Deleting the old zone first is the version that goes wrong. A server whose zone has been removed does not fall silent; it refuses or errors for a domain it is still listed for - lameness by definition - for as long as the old delegation stays cached.

Checking both sides yourself

Two questions, put to two different parties, settle most delegation problems.

First, ask the parent. A registry nameserver for your extension, queried about your domain, returns a referral: the delegation NS set in the authority section, plus glue in the additional section where the names are in-bailiwick. That is what the registry publishes, and it should match what your registrar's panel shows.

Second, ask each listed server directly, one at a time, for the zone's NS records, and read the response rather than only the records. An authoritative server answers from local knowledge and sets the authoritative-answer flag. A server that answers without it, refuses, or returns an error for a zone it is listed for is the lame one. Query each server by name rather than relying on your local resolver, because one cached good answer hides a bad server completely.

Then compare three lists: what your registrar shows, what the parent publishes, and what each server says about itself. Where they differ, the difference tells you which side to repair - the registry side through your registrar, the zone side at your DNS provider.