NS Lookup

An NS record (nameserver) is the DNS resource record that delegates a zone to a set of servers. It was defined in RFC 1035, and it is what makes the DNS a tree: the root zone holds NS records for com, the com zone holds NS records for example.com, and a resolver follows them down until it reaches a server that can answer for the name it wants.

example.com.  86400  IN  NS  ns1.example.net.
example.com.  86400  IN  NS  ns2.example.net.

The value is always a hostname, never an IP address, and RFC 2181 section 10.3 requires it to be a canonical name with its own A or AAAA records rather than a CNAME. NS records carry long TTLs, a day or two is typical.

An NS lookup returns the hostnames of the nameservers for a zone. Our DNS lookup tool asks Google Public DNS (8.8.8.8), Cloudflare (1.1.1.1), Quad9 (9.9.9.9) and OpenDNS at the same time and marks whether they agree, the first check after moving a domain to a new DNS provider.

NS records exist only at a zone apex, so an NS lookup on www.example.com returns nothing. The Nameservers button under every DNSX result handles that. It walks up to the closest enclosing zone, lists that zone's nameservers with their addresses, location and ASN, and asks each server directly with recursion disabled. A server that does not answer with the AA flag is marked, and the zone's SOA record is shown alongside.

Open Command Prompt or PowerShell. nslookup ships with every version of Windows, and Resolve-DnsName is the PowerShell cmdlet. Add a resolver address, as in the last two lines, to ask a public resolver instead of your network's.

nslookup -type=NS example.com
Resolve-DnsName -Type NS example.com
nslookup -type=NS example.com 8.8.8.8
Resolve-DnsName -Type NS example.com -Server 1.1.1.1

macOS ships dig, so no install is needed. Open Terminal and run one of these. The +short form prints only the record values, and the @ form sends the query to a specific resolver.

dig NS example.com
dig NS example.com +short
dig @1.1.1.1 NS example.com

dig and host come from the dnsutils package on Debian and Ubuntu and from bind-utils on Fedora and RHEL. The +noall +answer options print only the answer section, and +tcp forces the query over TCP when you suspect a truncated UDP answer.

dig NS example.com +noall +answer
host -t NS example.com

After you change a NS record, the authoritative nameservers answer with the new value immediately, and every recursive resolver that cached the old record keeps serving it until the cached TTL runs out. Our DNS lookup tool above shows whether Google, Cloudflare, Quad9 and OpenDNS agree yet, and the Authoritative option reads the value straight from the zone's own nameservers. The DNS propagation checker asks resolvers in more locations and lays the results out side by side.

Nameserver changes are the slowest to propagate because the parent zone publishes them with a TTL of 172,800 seconds (two days) for com and most other TLDs, so keep the old provider's zone live for two days after switching.

Every delegated zone has two copies of its NS set. The parent zone (com, for example.com) holds the copy your registrar publishes, and the zone apex holds the copy your DNS provider publishes. RFC 2181 section 5.4.1 ranks authoritative data above data learned from a referral, so when the two disagree, resolvers prefer the child's list once they have it.

That is why the two sets must match. If the registrar lists the old provider and the new provider's zone lists its own servers, some resolvers keep querying the old provider for as long as its zone stays online. Compare the public resolvers with the Authoritative option to see both copies.

If a nameserver is inside the zone it serves (ns1.example.com serving example.com), a resolver cannot look up ns1.example.com without first reaching example.com's nameservers. Glue records break that loop: the parent zone stores the A and AAAA records of in-zone nameservers and includes them in every referral, as RFC 1034 section 4.2.1 describes.

You need glue only when your nameserver names are under the domain they serve. Registrars call this registering a child nameserver and collect the IP addresses then. Stale glue, an address in the parent that no longer matches the server, is a classic cause of intermittent resolution failures.

A lame delegation is an NS record that points at a server which does not actually serve the zone. The server answers DNS, but replies without the AA (authoritative answer) flag, with a referral, or with REFUSED. RFC 1912 section 2.8 describes the problem. It happens when a provider is listed but never had the zone loaded, or when a secondary let the zone expire.

Lame servers make a domain slower rather than dead: resolvers rotate across the NS set and waste a query each time they land on the lame one. If every server is lame the domain stops resolving.

Every lookup on DNSX is also a JSON endpoint on api.dnsx.dev that you can call from curl or a script with no API key. The response has one result per resolver with its records and TTLs.

curl https://api.dnsx.dev/dns/ns/cloudflare.com