Guides • Last Updated 5th April 2026 • 3 min read

How to Read NS Records Correctly

Learn how to read NS records, understand what they say about delegation, and spot signs of stale nameservers, mismatches, or broken authority.

Tools For This Topic

Delegation Checker

Compare parent delegation, child NS records, and SOA serials.

CAA Analysis

Review certificate authority authorization records and tags.

Glue Record Checker

Inspect in-bailiwick nameservers and glue-related addressing.

What NS records are telling you

NS records identify the nameservers that are authoritative for a DNS zone. Reading them correctly means understanding both which servers are listed and whether those servers actually match the delegation and answer authoritatively.

A list of nameserver hostnames may look normal on the surface, but the real question is whether the parent zone, child zone, and actual server responses all agree.

Example NS records

example.com. 3600 IN NS ns1.provider.net.
example.com. 3600 IN NS ns2.provider.net.

This tells resolvers that ns1.provider.net and ns2.provider.net should be authoritative for example.com. That is the starting point, not the end of the analysis.

How to read the result usefully

Check whether the nameserver hostnames match the DNS provider you expect
Check whether the same NS set appears at both the parent and child level
Check whether the listed servers respond authoritatively for the zone
Check whether the nameservers themselves resolve correctly
Check whether any old or duplicate nameservers suggest migration drift

Common signs of NS trouble

Parent and child NS records do not match
A listed nameserver does not answer authoritatively
The NS set still includes a retired provider
In-bailiwick nameservers are present but glue is missing or wrong
One nameserver serves different zone contents from the others

These are usually delegation or migration issues rather than simple lookup issues, which is why NS data is best read alongside SOA and glue context.

If you are only checking a single recursive resolver, some of these problems can stay hidden. Direct nameserver comparison usually makes the issue much clearer.

How to review NS records in practice

Start with the NS set returned by a normal lookup, then compare it with a delegation-focused check and direct nameserver queries. If the zone is behaving inconsistently, look for mismatches between the parent delegation, the child zone, and the real server responses.

That workflow usually tells you whether the issue is stale delegation, a nameserver outage, missing glue, or a replication problem.

It also helps explain inconsistent resolver behaviour, because different caches or resolvers may encounter different authoritative paths when the delegation is unhealthy.

Use These DNS Pro Tools

If you want to validate this topic in practice, these DNS Pro tools are the fastest next step.