3,932 Australian domains analysed. Most fail basic email authentication. [2026 Report]

NS Record Lookup

See which nameservers are authoritative for a domain.

Perform NS Lookup

What is a NS record?

An NS record lists the authoritative nameservers for a domain — the DNS servers that hold the definitive answers for everything under that domain. NS records exist at two places in the DNS hierarchy: at the parent zone (e.g. the .com registry has NS records for example.com pointing to your provider) and at the child zone itself (your nameservers publish their own NS records saying "yes, we're authoritative for example.com").

When a resolver starts a fresh lookup for something under example.com, it first finds the NS records by walking down from the root (., then .com, then example.com). The parent zone's NS records are called the "delegation" — they tell the world who to ask. The child zone's NS records are called "in-zone NS" and are consulted once the resolver has reached the authoritative server.

Both sets should match. When they don't, you have a "lame delegation" — the parent says to ask server X, but server X doesn't claim authority. Resolvers handle lame delegation inconsistently: some fall through to the in-zone NS, some cache the lameness and fail, some serve stale data. Lame delegation is a frequent cause of intermittent "works on my machine" DNS failures.

Most domains publish 2–4 NS records for redundancy. Running fewer than two on production domains is risky — a single nameserver outage takes the whole domain offline from a DNS perspective, which cascades into email bounces, TLS certificate issuance failures, and more.

How to read the results

The result shows the authoritative nameservers for the queried domain. Most providers group their nameservers with predictable names: ns1.provider.com, ns2.provider.com, etc. Seeing four nameservers is common; two is the minimum for reliability; one is a risk you should fix.

If you've just migrated DNS providers and the NS records still show the old ones, check whether the change is propagating. NS changes happen at the registrar, and the parent zone's TTL for your domain's NS records is typically 48 hours — so "stale" NS results for up to two days after a migration are normal.

To check what the parent zone says (as opposed to what your current authoritative servers return), query the parent directly: dig +norec example.com NS @a.gtld-servers.net for .com domains. If the parent and child disagree, you have a delegation mismatch and need to reconcile them at the registrar.

Common issues

  • NS mismatch between registrar and zone (lame delegation). The parent zone (set at your registrar) and the in-zone NS records disagree. Fix by updating the registrar to match the zone, or vice versa. Both should be authoritative and consistent.
  • Only one nameserver listed. DNS best practice (and most TLD policies) require at least two nameservers. A single NS is both a reliability risk and may trigger registry warnings. Add a second NS and verify both answer identically.
  • NS records pointing to a nameserver that no longer exists. A forgotten secondary nameserver hostname that's been decommissioned. Resolvers will try it, time out, and eventually give up or fall through — introducing ~5–10 seconds of latency per lookup against a dead NS.
  • In-zone NS records missing. The parent zone delegates correctly to ns1.provider.com, but example.com itself publishes no NS records. Most resolvers accept the delegation anyway, but DNSSEC and some zone transfer tooling require in-zone NS records to be present and consistent with the delegation.
  • Recent migration, changes not yet propagated. Parent zone TTLs for NS records are typically 48 hours. If you just changed nameservers, expect a 1–2 day window where some resolvers still ask the old servers. Ideally, the old servers should keep serving the same zone data during the migration window, then be retired after 72 hours — abruptly turning them off causes resolution failures for clients still caching the old NS set.