NS Record Lookup

Find the authoritative Nameservers (NS) designated for a domain.

About NS Records

Nameserver (NS) records tell recursive resolvers which DNS servers are authoritative for a domain. If you change your DNS hosting provider, you must change your NS records at your registrar to point to the new provider's servers.

DNS standards require domains to have at least two authoritative nameservers for redundancy.

Our NS Record Lookup returns the authoritative name servers for any domain, along with the IP address each one resolves to. Use it to confirm which DNS provider controls a domain, verify a nameserver migration, or spot a delegation that has gone stale.

What is an NS Record?

An NS (Name Server) record identifies the authoritative DNS servers for a domain. These are the servers that hold the real zone file — the definitive answers for every A, MX, TXT and other record in that domain.

When a resolver looks up example.com, it starts at the root servers, is referred to the .com servers, and those return the NS records for example.com. The resolver then queries one of those name servers directly for the answer. This chain is called delegation.

NS records exist in two places at once: at the parent zone (the registry, set through your registrar) and inside the zone itself. Both should list the same servers. A mismatch between them causes intermittent and very hard to diagnose resolution failures.

Names the authoritative DNS servers that hold a domain zone file
Set at the registrar and mirrored inside the zone itself
A domain normally publishes between two and four name servers
Delegation from the parent zone is what makes a domain resolvable
Changing NS records moves the entire domain to a new DNS provider

Why NS Records Matter

NS records sit at the top of the entire DNS dependency chain. If they are wrong, nothing below them works — the website, email, and every subdomain go dark at once. There is no partial failure mode.

They also matter for security. Whoever controls your name servers controls every record in your domain, and can silently redirect your website and intercept your email. Nameserver hijacking is one of the highest-impact attacks against a domain, which is why registrar locks and registry locks exist.

A wrong NS record takes down website and email simultaneously
Whoever controls your name servers controls every DNS record you publish
Mismatched parent and child NS records cause intermittent failures
Nameservers all hosted by one provider are a single point of failure
Stale NS entries pointing at expired providers enable domain takeover

How This NS Record Lookup Works

The tool queries DNS for records of type NS and then resolves each returned nameserver hostname to its address.

Validates the domain input against format and SSRF safety checks
Queries DNS for records of type NS on the supplied domain
Collects every authoritative nameserver hostname returned
Resolves each nameserver hostname to its current IP address
Reports the TTL so you can judge how long a change will take to propagate

How to Use the NS Record Lookup

Enter a domain name such as example.com in the input field
Run the lookup to query live DNS
Review every authoritative nameserver returned
Confirm the servers match the DNS provider you expect to be using
Check that each nameserver resolves to a valid IP address

Understanding Your NS Record Results

Each NS record names one authoritative server. Here is what the returned fields mean:

Field / Value	Meaning
`Nameserver`	The fully qualified hostname of an authoritative DNS server, such as ns1.example-dns.com. This is where the real answers for your domain live.
`Resolved IP`	The address that nameserver hostname currently resolves to. A blank value means the nameserver hostname itself is broken, which will make your domain unreliable.
`TTL`	How long resolvers cache the delegation, in seconds. NS records often carry a long TTL of 86400 (24 hours), which is why nameserver changes take up to two days to settle.
`Record count`	Two to four nameservers is standard. A single nameserver is a single point of failure. More than six adds little redundancy and slows resolution for some clients.
`Provider mix`	If every nameserver belongs to one company, an outage at that company takes your domain offline. Some organisations deliberately split delegation across two independent DNS providers.

Common Problems & How to Fix Them

A single nameserver means any outage or maintenance on that host takes your entire domain offline, including email.

Most registries require at least two. Add a second nameserver at your DNS provider — nearly all of them supply several by default — and update the delegation at your registrar to list all of them.

The NS records inside your zone disagree with the delegation stored at the registry. Resolvers may cache either answer, producing failures that appear random and only for some users.

Log in to your registrar, note the nameservers listed there, and make the NS records inside your DNS zone match them exactly.

An NS record points at a hostname with no A or AAAA record, so resolvers cannot reach it.

This usually happens after a provider change where old records were left behind. Remove the obsolete NS record, or if it is meant to be in use, add the missing glue record at your registrar.

NS records commonly carry a 24 or 48 hour TTL, so the old delegation stays cached long after you change it.

Before a planned migration, create the full zone at the new provider first, confirm it answers correctly when queried directly, and only then switch the delegation at the registrar. Never delete the old zone until propagation has fully completed.

Best Practices

Publish at least two nameservers, and confirm they are on separate networks
Keep the NS records inside your zone identical to the delegation at your registrar
Verify the new provider answers correctly before switching delegation
Never delete the old DNS zone until propagation has fully completed
Consider splitting delegation across two independent DNS providers for critical domains
Check nameserver hostnames resolve to valid addresses after any infrastructure change
Review NS records periodically as part of your domain inventory

Security Recommendations

Enable registrar lock and, for high-value domains, registry lock to prevent unauthorised nameserver changes
Monitor NS records for unexpected changes — a silent nameserver swap is a full domain takeover
Remove NS records pointing at providers or accounts you no longer control, which enable dangling delegation attacks
Enable DNSSEC so resolvers can verify that answers really came from your authoritative servers
Use multi-factor authentication on both your registrar and DNS provider accounts
Test that your nameservers refuse zone transfers (AXFR) to arbitrary clients

Frequently Asked Questions

An NS record identifies an authoritative name server for a domain — a server that holds the domain real zone file and can answer definitively for its records. Resolvers follow NS records down from the root to find where to ask for a domain DNS data.

Two to four is standard and most registries require a minimum of two. A single nameserver is a single point of failure that can take your website and email offline together. More than six provides little extra benefit.

NS records usually carry a long TTL, often 24 or 48 hours, so a nameserver change can take up to two days to propagate fully. Build the zone at the new provider and verify it before switching delegation, and leave the old zone in place throughout.

An NS record names a nameserver by hostname. A glue record supplies that nameserver IP address at the parent zone. Glue is required when the nameserver lives inside the domain it serves — for example ns1.example.com serving example.com — otherwise resolution would be circular.

The delegation at the registry and the NS records inside your zone are stored separately and can drift apart. Resolvers may cache either version, causing intermittent failures. Make them match exactly.

Yes, and for critical domains it is a recommended resilience measure. Both providers must serve identical zone data, usually kept in sync by zone transfer or by an API-driven pipeline. It protects you from a complete outage at either provider.

Your entire domain stops resolving — website, email, subdomains, everything at once. Unlike most DNS mistakes there is no partial failure; NS records sit at the top of the dependency chain.