🏛️ How to check an authoritative server

$ dig -4 @coleman.ns.cloudflare.com isitdns.net SOA +norecurse

Step 1: find out who the authorities are#

NS records list the nameservers for a zone. Ask a public resolver, not your own, so the answer does not depend on a resolver that could itself be the thing that's broken:

dig @1.1.1.1 isitdns.net NS +short

Real output:

coleman.ns.cloudflare.com.
hera.ns.cloudflare.com.

Reading it: two authoritative nameservers, in no particular order. Either answers correctly. Two or more is required practice (RFC 2182 section 5 requires at least two servers per zone), so one going down does not take the zone offline.

The trailing dot means the name is complete, ending at the root. See NS records for the full story.

Step 2: ask one of them directly#

Ask that server yourself, with recursion off so you're testing only what it personally knows (dig-flags covers every flag):

dig -4 @coleman.ns.cloudflare.com isitdns.net SOA +norecurse

That's the query shown at the top of this page. See SOA records for what each field in the answer means; the third field is the serial, the one the next two steps care about.

Step 3: read the answer#

The flags line is what matters.

If aa is there, you succeeded. The server answered from its own zone data. No cache is involved.

If aa is missing, one of three things happened:

1. You asked a server that does not own this zone. Check the name you used in step 1.
2. Your network intercepted the query and a resolver answered instead. See the interception check on the troubleshooting index. The giveaway is ra being set.
3. The server owns a different zone than the one you asked about.

Step 4: check every authority agrees#

The most common real-world failure: one nameserver quietly missing the latest update, so a name works for some users and not others. Ask every authority for the serial and print them side by side:

for ns in $(dig +short NS isitdns.net); do
  echo "$ns -> $(dig -4 @"$ns" +short isitdns.net SOA | awk '{print $3}')"
done

Real output:

hera.ns.cloudflare.com. -> 2410489729
coleman.ns.cloudflare.com. -> 2410489729

Reading it: both servers report the same serial (RFC 1034 §4.3.5). This is what matching serials look like.

If the numbers differ, the server with the older serial (RFC 1982 §3.2) has not received the latest update. Its copy is stale, and any user who happens to ask that server gets old answers. That is a zone transfer problem: see zone transfers.

Quick reference#

The header line of any dig output ends with status:, and that word is the diagnosis.

See also#

• check-a-delegation: whether the parent agrees these are the right nameservers
• check-a-forwarder: the other direction, when you are sending queries somewhere
• Nameserver consistency: the SOA serial at every server of a zone, the other records at a sample