NS (name server) is the DNS record type that names the authoritative name servers for a DNS zone. Among DNS records, it performs two roles: in the parent zone it delegates authority for a domain to specific servers, and at the apex of the zone itself it declares which servers are authoritative for that zone’s data.
An NS record always points to a host name, never to an IP address. Resolvers then look up the A or AAAA records of that host name to reach the server. Without correct NS records a domain cannot be resolved at all, which makes NS the foundation on which every other record type depends.
How NS records delegate a domain
DNS is a hierarchy of zones, and NS records are the links between them. The root zone contains NS records for each TLD, and a TLD zone such as .com contains NS records for each registered domain. A recursive resolver follows these referrals downward until it reaches a server that holds the answer authoritatively.
- The resolver asks a root server for shop.example.com and receives NS records for .com.
- It asks a .com server and receives a referral with the NS records for example.com.
- It resolves the name server host names to addresses, using glue records when provided.
- It asks an authoritative server for example.com, which returns the final answer.
- It caches every NS set for the duration of its TTL to skip these steps next time.
A referral is not an authoritative answer. The NS records in the parent are delegation data, while the matching NS set at the child apex is authoritative data. Resolvers generally prefer the child’s version once they have it, so both copies should match.
Record format and key parameters
An NS record has the usual DNS fields: owner name, TTL, class, type and data. The data is a single domain name of a name server, written as a fully qualified name in zone files, such as ns1.example.net. with a trailing dot.
| Field | Example | Notes |
|---|---|---|
| Owner name | example.com. | Zone apex or delegated subdomain |
| TTL | 3600 to 172800 seconds | Delegations in TLDs often use one to two days |
| Class | IN | Internet class in practice |
| Type | NS | Name server record |
| Target | ns1.example.net. | Host name with its own A or AAAA records |
Most registries require at least two name servers per domain, and good practice is to place them on separate networks and locations, often through anycast. Long NS TTLs improve resilience and reduce query load, but they also mean that changes of DNS provider propagate slowly.
Glue records and in-bailiwick name servers
A circular dependency arises when a domain’s name server lies inside the domain it serves, for example ns1.example.com for example.com. The resolver cannot look up the server’s address without first reaching that same server. Glue records solve this: the parent zone publishes the A and AAAA records of those name servers alongside the delegation.
| Name server host | Domain served | Glue required |
|---|---|---|
| ns1.example.com | example.com | Yes, the server is inside the delegated zone |
| ns1.dnshost.net | example.com | No, its address resolves independently |
| ns.sub.example.com | sub.example.com | Yes, in the example.com zone |
| ns1.example.org | example.com | No, unless example.org itself depends on example.com |
Glue is registered through the registrar as host objects at the registry. When a name server’s IP address changes, the glue must be updated as well; otherwise resolvers keep reaching the old address for as long as the parent publishes it.
NS compared with other DNS record types
NS differs from most other record types because it describes the structure of DNS itself, not a service of the domain. Several records nevertheless interact closely with it.
| Record | Purpose | Relation to NS |
|---|---|---|
| NS | Names authoritative servers, delegates zones | Defines where the zone is served |
| SOA | Zone metadata, primary server, serials and timers | Appears with NS at every zone apex |
| A and AAAA records | Map names to IPv4 and IPv6 addresses | Resolve NS targets and act as glue |
| CNAME | Aliases one name to another | Must not coexist with NS and is not a valid NS target |
| MX | Names mail servers | Also points to host names, like NS |
The DNS specifications forbid an NS target that is an alias defined by a CNAME, and a name that has NS records for delegation cannot also carry a CNAME. Breaking these rules causes inconsistent resolution across resolver implementations.
Common NS misconfigurations
NS errors tend to cause partial or intermittent failures, because resolvers pick among listed servers and only some of them may be broken. Diagnosing them requires querying the parent and each listed server directly.
- Lame delegation: a listed server does not answer authoritatively for the zone, causing timeouts and retries.
- Parent and child mismatch: different NS sets in the TLD and at the apex confuse resolvers after migrations.
- Single point of failure: all name servers in one network or data center fail together.
- Stale glue: outdated glue addresses send queries to retired servers.
- Premature shutdown during migration: switching off old servers before cached NS records expire breaks resolution.
A safe provider migration keeps both old and new servers serving identical data until the old NS TTLs, including the parent delegation TTL, have fully expired. With DNSSEC enabled, the DS record must be coordinated with the change as well.
Explained without jargon
Finding a website starts with finding who keeps the official records for its name. NS records answer exactly that. They work like a signpost in a large building directory: the main directory does not list every office, but it says which floor reception knows the details.
When a domain changes hosting company, the signpost must be updated to point to the new reception desk. If the signpost is wrong, nobody can find anything else about the domain, no matter how correct the other records are.
A typical use case
A software company moves the DNS of its main domain from its registrar’s basic service to a managed DNS provider with anycast name servers. The current delegation lists two registrar name servers with a parent TTL of 48 hours.
The team first recreates every record at the new provider and verifies each one by querying the new servers directly. It then replaces the NS records at the registrar with the four new name servers and leaves the old service running unchanged for a full week.
During the transition, resolvers with cached delegations still reach the old servers and receive identical answers, while others move to the new ones. No visitor experiences an outage, and after the old NS records expire everywhere, the company decommissions the old zone and gains name servers spread across many locations.