📜 NS Lookup Tool

🔍 What Is an NS Record?

An NS (Name Server) record is DNS's way of pointing at authority itself. It doesn't hold an address, a mail server, or a text value — it holds the hostname of a server that is allowed to give official, binding answers about a zone. When any resolver anywhere needs to find out what a domain's mail server is, what its website resolves to, or what any subdomain contains, it eventually has to ask one of that domain's listed name servers, because those are the only servers the rest of the DNS hierarchy has agreed to trust for that particular piece of namespace.

This matters more than most single record types because everything else depends on it. A wrong A record breaks one hostname. A wrong or missing NS delegation can break the entire domain — every subdomain, every mail route, every service — because nothing downstream can even be discovered if the authority chain pointing to it is broken. This tool exists to make that chain visible: which name servers are currently delegated, whether they're reachable, and whether the picture at the registry actually matches what the domain's own zone believes.

📋 Record Structure & Syntax

An NS record's syntax is short and purely referential — a zone name, a TTL, a class, the record type, and the hostname of a name server:

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

Domains almost always publish more than one NS record for the same zone — that's not redundancy for its own sake, it's a structural requirement most registries and RFC 1035 conventions expect, so that a single unreachable name server never takes an entire domain offline. NS records typically carry a longer TTL than most other record types, often 24 to 48 hours, because delegation is meant to be stable infrastructure, not something that changes often.

⚙️ How This Tool Queries Delegation

When you click Lookup, the tool sends a live NS query for the domain against a public DNS resolver, retrieves every name server currently published, and then queries each one individually for its own A and AAAA address so you can see exactly where each server actually lives on the internet, not just its hostname.

🏮 Parent vs. Child: Why Two Copies Exist

Here's the part that trips up almost everyone the first time they hit it: a domain's NS records actually exist in two separate places that are supposed to agree, but don't have to. The registry — the organization that runs the parent zone, like .com or .org — stores its own copy of the delegation, which is what the rest of the internet actually follows first. Separately, the domain's own zone file, hosted wherever its DNS is managed, contains a second copy of the same NS records at the zone apex.

Under normal conditions these two copies match exactly. They can drift apart, temporarily, during a DNS provider migration: someone updates the registry's delegation to point at the new provider, but the old provider's zone file — if it's still reachable — might still be serving an outdated internal copy of the NS records. Resolvers follow the registry's copy to find the domain in the first place, so that's the one that actually controls where traffic goes; the internal zone copy is more of an internal consistency check. A live delegation check like this one is the fastest way to see, in one place, exactly what's currently published at the level that matters.

🔗 Glue Records, Briefly

A glue record solves a specific chicken-and-egg problem: what happens when a domain's name server hostname lives inside the very domain it's supposed to serve? Asking "what's the IP of ns1.example.com" would normally require asking example.com's name servers — but ns1.example.com is one of them. To break that loop, the parent zone stores the name server's IP address directly, alongside the delegation, so a resolver never has to circle back on itself. That directly-attached IP is the glue record.

Glue is only required when a name server's hostname is inside (or a subdomain of) the zone it serves — commonly called in-bailiwick name servers. A name server hosted on a completely separate domain, like a third-party DNS provider's own infrastructure, doesn't need glue, because resolving its address doesn't create a circular dependency in the first place. Missing or stale glue is a genuinely common cause of "my domain won't resolve for some people but works for others" tickets.

🗺️ Where NS Records Sit in the Resolution Flow

NS records are the connective tissue of the entire DNS hierarchy. A resolver starts at the root, gets referred to the TLD's name servers via NS records, gets referred again from there to the domain's own name servers via another set of NS records, and only then finally asks those servers for the actual A, MX, TXT or other record it originally wanted. Every single DNS lookup on the internet passes through at least two layers of NS-record referral before it ever reaches the record type most people think of as "the answer."

📊 Comparison Tables

Parent Zone vs. Child Zone Delegation

Registrar vs. Registry vs. DNS Provider

🌐 Real-World Examples

🛡️ Name Server Setups Across Providers

Every major DNS provider assigns a domain a fixed pair (or larger set) of branded name server hostnames the moment a zone is created there — Cloudflare, for instance, assigns two from a large shared pool; AWS Route 53 assigns four unique ones per hosted zone; Google Cloud DNS and Azure DNS follow broadly similar patterns. Updating delegation always means changing these hostnames at the registrar, not inside the DNS provider itself — the provider only controls what happens after a resolver arrives, not whether it arrives in the first place.

🖥️ Command-Line Reference

🔁 Redundancy & Anycast

Almost every serious DNS provider serves its name servers via anycast — the same hostname and IP address announced from dozens of physical locations worldwide, with routing automatically sending each query to the nearest healthy location. From the outside, an anycast name server still shows up as one hostname with one IP in an NS lookup, but underneath it, a single query can be answered by a data center in a completely different city than the last one, purely based on network topology and current health at query time.

🔒 Security Considerations

Delegation is one of the highest-value targets in domain security, because whoever controls a domain's name servers effectively controls every other record inside it — email, website, everything. Domain hijacking via unauthorized NS change is a genuinely serious attack pattern: gain access to a registrar account, repoint delegation to attacker-controlled name servers, and suddenly every service tied to that domain can be silently redirected. Registrar-level protections — two-factor authentication, a registry lock, and monitoring for unexpected delegation changes — are the practical defenses, and this kind of live NS check is a reasonable first move whenever a domain starts behaving unexpectedly.

⏱️ Performance & Caching

NS records typically carry a long TTL, often in the 24–48 hour range, because delegation is meant to change rarely — this reduces load on the parent zone's servers but also means changes take longer to fully propagate everywhere. Resolvers cache the delegation itself, not just the individual records under it, so a fresh delegation change can take up to that TTL to be visible from every vantage point, even though your own DNS provider's zone might already be serving the intended records correctly.

❌ Common Mistakes

✅ Best Practices

Use at least two, ideally four, name servers spread across genuinely independent networks or providers, so a single outage can't take the whole domain offline. Keep the registry delegation and the zone file's own NS records in sync at all times, and re-verify both immediately after any provider migration. Enable a registry lock and two-factor authentication on the registrar account, since delegation is one of the highest-value single points of control over a domain. Document glue-record requirements clearly before self-hosting name servers under your own domain.

📊 Pros & Cons of Common Setups

🔧 Troubleshooting

📚 Glossary

🎓 Expert Tips

🔗 More Ways to Investigate DNS

For the complete record picture beyond NS, use DNS Lookup. To confirm whether a delegation change has propagated globally, use DNS Propagation Checker. Check domain ownership and registrar details with WHOIS Lookup, and trace hostname aliasing with CNAME Lookup. For the underlying address behind a name server, try A Record Lookup or AAAA Record Lookup.