How to check ns record

Ask the zone: nslookup -type=NS mozilla.org 8.8.8.8. Then ask a nameserver of the parent zone for the same name and compare the two lists. Read the SOA with -type=SOA and note the serial. The parent answers in the authority section, the zone's own server sets the authoritative flag.

Checker offline. Follow the manual steps below, they give the same answer.

Why check this

Run this the day a domain changes DNS provider, and again on the release after it. Two lists of nameservers exist for every zone. The parent holds the delegation, the zone holds its own NS set, and the zone owner edits only the second one. When they disagree, some resolvers follow one list and some follow the other, so the name resolves for part of your users and fails for the rest, with no pattern anyone can reproduce on demand.

The SOA answers a different question. It names the server the zone is edited on and carries a serial that changes with every edit. Reading the serial from each nameserver in turn tells you whether every copy of the zone is the same copy.

Prerequisites

nslookup with the -debug flag, which prints the header flags, the record sections and the TTL. Without it you cannot tell a referral from an answer.
A nameserver of the parent zone. For .org that is a name like a0.org.afilias-nst.info, for .com a name like a.gtld-servers.net. Any one of them will do.
RFC 1034 section 4.2.2 for how a delegation is written at the parent and repeated inside the zone.

Steps

Read the NS set the zone publishes about itself.

nslookup -type=NS mozilla.org 8.8.8.8

Non-authoritative answer:
Server:  dns.google
Address:  8.8.8.8

mozilla.org	nameserver = ns5-65.akam.net
mozilla.org	nameserver = ns7-66.akam.net
mozilla.org	nameserver = ns1-240.akam.net
mozilla.org	nameserver = ns4-64.akam.net

Ask the parent zone for the delegation, with the debug flag so the sections are visible.

nslookup -debug -type=NS mozilla.org a0.org.afilias-nst.info

Got answer:
  HEADER:
opcode = QUERY, id = 1, rcode = REFUSED
header flags:  response, want recursion
questions = 1,  answers = 0,  authority records = 0,  additional = 0

  QUESTIONS:
1.56.19.199.in-addr.arpa, type = PTR, class = IN

------------
Server:  UnKnown
Address:  199.19.56.1

------------
Got answer:
  HEADER:
opcode = QUERY, id = 2, rcode = NOERROR
header flags:  response, want recursion
questions = 1,  answers = 0,  authority records = 4,  additional = 0

  QUESTIONS:
mozilla.org, type = NS, class = IN
  AUTHORITY RECORDS:
  ->  mozilla.org
nameserver = ns4-64.akam.net
ttl = 3600 (1 hour)
  ->  mozilla.org
nameserver = ns1-240.akam.net
ttl = 3600 (1 hour)
  ->  mozilla.org
nameserver = ns7-66.akam.net
ttl = 3600 (1 hour)
  ->  mozilla.org
nameserver = ns5-65.akam.net
ttl = 3600 (1 hour)

The first block is not your query. It is nslookup asking the server for its own reverse name, and the TLD server answering rcode = REFUSED, which is why the next line reads Server: UnKnown. The second block is the query you typed. answers = 0, authority records = 4 is a referral, not an answer. The four names are the delegation. They match step 1, which is what a healthy zone looks like.

Ask one of those nameservers the same question, and watch the flags change.

nslookup -debug -type=NS mozilla.org ns1-240.akam.net

Got answer:
  HEADER:
opcode = QUERY, id = 2, rcode = NOERROR
header flags:  response, auth. answer, want recursion
questions = 1,  answers = 4,  authority records = 0,  additional = 0

  QUESTIONS:
mozilla.org, type = NS, class = IN
  ANSWERS:
  ->  mozilla.org
nameserver = ns4-64.akam.net
ttl = 3600 (1 hour)
  ->  mozilla.org
nameserver = ns5-65.akam.net
ttl = 3600 (1 hour)
  ->  mozilla.org
nameserver = ns7-66.akam.net
ttl = 3600 (1 hour)
  ->  mozilla.org
nameserver = ns1-240.akam.net
ttl = 3600 (1 hour)

auth. answer and answers = 4. Same four names, this time in the answer section, from the zone itself. Compare this list with the list in step 2. Any name in one and not the other is the defect this page exists for.

Read the SOA serial from every nameserver of a zone. Save this as serial.js and run node serial.js mozilla.org, then node serial.js github.com.

const { Resolver } = require('node:dns');
const zone = process.argv[2];
const boot = new Resolver();
boot.setServers(['8.8.8.8']);
boot.resolveNs(zone, async (e, nsNames) => {
  if (e) return console.log(e.code);
  for (const ns of nsNames.sort()) {
    const ip = await new Promise((d) => boot.resolve4(ns, (er, a) => d(er ? null : a[0])));
    if (!ip) { console.log(ns.padEnd(26) + ' no address'); continue; }
    const r = new Resolver({ timeout: 5000, tries: 2 });
    r.setServers([ip]);
    const soa = await new Promise((d) => r.resolveSoa(zone, (er, s) => d(er ? er.code : s)));
    console.log(
      ns.padEnd(26) + ' ' +
      (typeof soa === 'string' ? soa : `serial=${soa.serial}  primary=${soa.nsname}  minttl=${soa.minttl}`)
    );
  }
});

ns1-240.akam.net           serial=2024020801  primary=ns5-65.akam.net  minttl=60
ns4-64.akam.net            serial=2024020801  primary=ns5-65.akam.net  minttl=60
ns5-65.akam.net            serial=2024020801  primary=ns5-65.akam.net  minttl=60
ns7-66.akam.net            serial=2024020801  primary=ns5-65.akam.net  minttl=60

dns1.p08.nsone.net         serial=1656468023  primary=dns1.p08.nsone.net  minttl=3600
dns2.p08.nsone.net         serial=1656468023  primary=dns1.p08.nsone.net  minttl=3600
dns3.p08.nsone.net         serial=1656468023  primary=dns1.p08.nsone.net  minttl=3600
dns4.p08.nsone.net         serial=1656468023  primary=dns1.p08.nsone.net  minttl=3600
ns-1283.awsdns-32.org      serial=1  primary=ns-1707.awsdns-21.co.uk  minttl=86400
ns-1707.awsdns-21.co.uk    serial=1  primary=ns-1707.awsdns-21.co.uk  minttl=86400
ns-421.awsdns-52.com       serial=1  primary=ns-1707.awsdns-21.co.uk  minttl=86400
ns-520.awsdns-01.net       serial=1  primary=ns-1707.awsdns-21.co.uk  minttl=86400

The first block is one zone on four servers, and the serial matches on all four. The second block is one zone published independently by two vendors. The four NS1 servers report serial 1656468023, the four Route 53 servers report serial 1, and the primary name and the minimum TTL differ too.

How to read the result

| What you see | What it means | What to do | | --- | --- | --- | | answers = 0, authority records = 4 | A referral. This server is delegating, not answering | Read the names as the delegation held at the parent | | header flags: ... auth. answer | The zone's own server answered from the zone | Treat this list as what the zone owner published | | The two lists match | Delegation and zone agree, resolvers cannot split | Nothing | | A name in one list and not the other | Resolvers that cached the parent use one set, the rest use the other | Fix the side that is stale, then wait out the parent TTL | | One serial on every nameserver | Every copy of the zone is the same copy | Nothing | | Two serials split by provider | Two vendors publish the zone independently | Compare serials inside a provider, never across two | | Server: UnKnown above the answer | nslookup could not reverse-resolve the server address | Ignore it. The query below it still ran |

Common mistakes

Sign: A cutover runbook says the serial went up, so the change is live, and half the resolvers still return the old record.Cause: The serial in step 4 is per server, not per zone. For github.com one set of nameservers reports 1656468023 and the other reports 1, because two providers publish the same zone from two different pipelines. A serial is only comparable against the same provider's other servers.

Sign: nslookup prints Server: UnKnown when a TLD server or an authoritative server is named, and the run is written off as a failure.Cause: nslookup reverse-resolves the server address before it sends your query. A TLD server answers that PTR query with rcode = REFUSED, so the name is unknown and the line says so. The query you asked for is sent anyway and its answer follows.

Sign: The NS list from a public resolver is used as the delegation.Cause: A recursive resolver returns the NS set it found inside the zone, cached under the zone's own TTL. The delegation lives at the parent and can differ. Step 2 is the only one of the three that reads it, and it needs a parent nameserver as the last argument.

What to check next

How to check dns records: every other type at the same name, in one sweep.
How to check dns propagation: what to do after the delegation changes, and why nothing travels.
How to check dns ttl: the 3600 in steps 2 and 3, and how long a nameserver change is held.
How to check ptr record: the reverse lookup that produced Server: UnKnown above.
How to check mx records: the records that stop working first when a delegation is half moved.

FAQ

How to check soa record?

nslookup -type=SOA mozilla.org 8.8.8.8 prints the primary nameserver, the responsible address, the serial, the refresh, retry and expire timers and the negative-answer TTL. Ask each nameserver of the zone in turn when you need to know whether the copies agree.

What should the SOA serial be after an edit?

Higher than before, on the provider that holds the zone. Many providers use the date form YYYYMMDDnn, some use a Unix timestamp, and Route 53 leaves it at 1 permanently. The value matters only as a comparison against the previous value from the same source.

How do I find a nameserver for the parent zone?

nslookup -type=NS org 8.8.8.8 lists the nameservers of .org, and the same works for any TLD. Pick one and use it as the last argument in step 2.

Can a zone list more nameservers than the parent delegates to?

It can, and resolvers will use both sets over time. Every server in either list has to serve the zone correctly, so the extra names are a liability until the two lists match.

Verified

Verified 2026-09-11by Maks Vernynslookup Windows 11 build 22631node 22.23.2

Each output block is what the command above it printed on that date, on the host named in the step. Figures read from a live site move between runs. Compare the shape of the answer rather than the digits, and see the methodology for how a page is re-verified.

Checker: dns-records A, AAAA, CNAME, MX, NS, TXT with TTL from two public resolvers, mismatch between resolversserver
DNS migration checklist13 checks
All email and dns checkscluster

intermediate8 minpublished 2026-09-11updated 2026-09-11Maks Verny