BRev NS record — authoritative nameservers
NS records say which servers are authoritative for a zone, and they exist in two places at once. The parent zone — the TLD registry, populated by your registrar — publishes a delegation, and the zone itself publishes its own NS set at the apex. Resolvers follow the parent’s copy to find you and then generally trust the zone’s own, so the two disagreeing is a real problem that both sides look fine in isolation.
Delegation also creates a chicken-and-egg problem when the nameservers live inside the zone they serve: to look up ns1.example.com you must ask the servers for example.com, which is ns1.example.com. Glue records break the loop — the parent publishes the address alongside the delegation. This is why changing the IP of an in-zone nameserver means updating glue at the registrar, not only the A record in your own zone.
Lame delegation is the failure worth naming: the parent points at a server that does not answer authoritatively for the zone — decommissioned, misconfigured, or a former provider that removed your zone when you left. Resolvers retry the remaining servers, so the symptom is intermittent slowness and scattered failures rather than a clean outage, which makes it one of the hardest DNS faults to pin down.
What a NS record looks like
Type 2 · Authoritative nameservers. Zone-file form below — owner name, TTL, then the record and its RDATA.
| Name | TTL | Record | What it means |
|---|---|---|---|
| example.com. | 86400 | NS ns1.example-dns.net. | One authoritative server. NS records carry a long TTL because delegation rarely changes. |
| example.com. | 86400 | NS ns2.example-dns.net. | A second server on different infrastructure — two is the practical minimum. |
| internal.example.com. | 86400 | NS ns1.internal-dns.example.com. | Delegating a subdomain to a different set of servers, so another team runs that zone. |
The mistakes that break production
Changing nameservers at the registrar and nowhere else
The delegation now points at the new provider while the old zone is still live — and if the new provider’s zone is incomplete, records go missing the moment the delegation takes effect. Build the zone fully at the new provider, verify by querying its servers directly, and only then change the delegation. Registry NS TTLs are long, so the change is slow to undo.
Removing a nameserver without removing the delegation
Lame delegation: the parent still lists a server that no longer answers for the zone. Resolvers time out on it and retry another, so the site is intermittently slow rather than broken, and the cause is invisible from a single successful lookup. Query each listed nameserver individually to find the one that no longer answers.
Query a NS record now
The box below is seeded with example.com. Choose NS as the type and press Look up — the query goes from your browser straight to Cloudflare or Google over DNS-over-HTTPS, with no server of ours in the path.
DNS is the internet's address book: it turns a name like example.com into the addresses and service endpoints machines actually connect to. Every record has a type (what kind of fact it states) and a TTL (how long resolvers may cache it).
Record types
| Type | What it stores |
|---|---|
| A | IPv4 address |
| AAAA | IPv6 address |
| CNAME | Canonical name (alias) |
| MX | Mail exchanger (priority target) |
| TXT | Text — SPF, verifications, DKIM, arbitrary data |
| NS | Authoritative nameservers |
| SOA | Start of authority (serial, refresh, retry, expire, minimum) |
| SRV | Service locator (priority weight port target) |
| CAA | Which CAs may issue certificates |
| PTR | Reverse DNS (IP → name) |
| DNSKEY | DNSSEC public key |
| DS | Delegation signer (DNSSEC chain of trust) |
| HTTPS | HTTPS service binding (ALPN, ECH, hints) |
| SVCB | General service binding |
| TLSA | DANE — pin certificates in DNS |
| NAPTR | Name authority pointer (SIP/ENUM) |
TTL & “propagation”
DNS changes don't “push” anywhere — resolvers simply keep the old answer until its TTL runs out, then fetch the new one. So a change “propagates” in at most the old record's TTL. Planning a change? Lower the TTL (e.g. to 300s) a day in advance, make the change, then raise it back. The compare card above shows whether major public caches have picked your change up yet.
FAQ
How many nameservers should a domain have?
At least two, and ideally on separate networks or providers — many registries require two. More than four adds little; diversity of infrastructure matters more than count.
What is a glue record?
An address record the parent zone publishes alongside the delegation, needed when the nameserver’s name is inside the zone it serves. Without it, resolution loops. Glue lives at the registrar, so changing that server’s address means updating it there too.
Why do my NS records differ from what the registrar shows?
You are comparing two different sets: the parent’s delegation and the zone’s own apex NS records. They should match. When they do not, resolvers can behave inconsistently — fix both.