Troubleshooting

🪜 How to check a delegation

A delegation is the handoff where one zone says "everything under this name is somebody else's job now." Two different servers hold an opinion about who that somebody is. When those opinions differ, resolution becomes a coin flip.

Background on the concept is in delegations. This page is the check.

The idea in one picture#

.net  (the parent)          "isitdns.net? Ask these two servers."
  |
  v
isitdns.net  (the child)    "I am isitdns.net, and my nameservers are these two."

Two separate places store a list of nameservers for the same zone. The parent stores it as part of the handoff. The child stores it inside its own zone as NS records. This split is built into the protocol: RFC 1034 §4.2.1 marks the boundary of a zone, the "cut", with NS records held by the parent, while the child keeps its own copy at the apex. Nobody automatically keeps them in sync. You update one and forget the other, and now they disagree.

Step 1: find the parent's servers, then ask one#

The parent of isitdns.net is the .net zone itself. You do not have to memorise its servers, you ask DNS for them, the same way you would for any zone:

dig @1.1.1.1 +short net. NS

The trailing dot matters: net. means "the TLD itself", not a hostname. Real output:

a.gtld-servers.net.
b.gtld-servers.net.
c.gtld-servers.net.
d.gtld-servers.net.

Reading it: these are the .net zone's authoritative servers, and any one of them will do. The same trick works for every TLD: dig @1.1.1.1 +short com. NS for a .com name, dig @1.1.1.1 +short org. NS for .org, dig @1.1.1.1 +short io. NS for .io.

Now ask one of them what it holds for our zone:

dig @a.gtld-servers.net isitdns.net NS +norecurse

@a.gtld-servers.net: one of the .net servers you just found.
+norecurse: do not go and look it up, just tell me what you personally hold.

The parent does not consider itself authoritative for the child, so its answer arrives in the authority section rather than the answer section:

;; AUTHORITY SECTION:
isitdns.net.		172800	IN	NS	hera.ns.cloudflare.com.
isitdns.net.		172800	IN	NS	coleman.ns.cloudflare.com.

Reading it: the parent believes two servers are in charge, and it hands out that list with a TTL of 172800 seconds, which is 48 hours. That long TTL is why delegation mistakes hurt: a wrong answer here can stay cached across the internet for two days.

This kind of response, pointing you somewhere else rather than answering, is called a referral.

Step 2: ask the child#

Now ask one of those nameservers the same question:

dig @coleman.ns.cloudflare.com isitdns.net NS +short

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

Reading it: the child names the same two servers. This is the zone's own opinion about who runs it.

Step 3: compare#

Put the two lists side by side. They should be identical, ignoring order.

Result	Verdict
identical lists	healthy, nothing to do
parent lists a server the child does not	that server may not actually serve the zone, and resolvers sent there can fail
child lists a server the parent does not	that server is invisible to most of the internet, because resolvers follow the parent

In our example both sides list coleman and hera, so this delegation is consistent.

Doing both steps at once:

echo "parent:"; dig @a.gtld-servers.net isitdns.net NS +norecurse +short
echo "child:";  dig @coleman.ns.cloudflare.com isitdns.net NS +short

What a mismatch actually does to you#

Resolvers follow the parent's list when they first find their way to your zone. So:

A nameserver the parent lists but that is not really serving your zone becomes a lame delegation, the RFC 8499 term for a delegation pointing at a server that does not answer authoritatively for the zone. Some fraction of queries land on it and fail. Users see intermittent, unreproducible breakage, and whoever reports it is always the one person whose shoulder you cannot look over.
A nameserver the child lists but the parent does not is simply not used by most of the internet, no matter how correctly it is configured.

Both failure modes are intermittent, which is what makes them expensive. Nothing is fully down, so nothing gets escalated, and the symptom moves around.

Step 4: check each listed server actually answers#

A name on the list means nothing until the box behind it responds. Test every one:

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

This walks the parent's list and asks each server for the zone's serial number.

What you want: every server prints the same number.

What the failures mean:

blank or an error for one server: it is not answering for this zone. That is a lame delegation, and it is the thing to fix first.
a different number: that server holds an older copy of the zone. Not lame, but stale. See zone transfers.

Glue, and when you need it#

If a zone's nameservers are named inside the zone they serve, there is a chicken-and-egg problem. To find ns1.example.com you must ask example.com's nameservers, and ns1.example.com is one of them.

The parent solves it by publishing glue: the IP addresses alongside the referral, so a resolver can proceed. RFC 1034 §4.2.1 names these glue RRs and requires them exactly in this case, when the nameserver's name sits below the cut. Glue shows up in the additional section of the parent's response.

You only need glue when the nameserver names live inside the zone being delegated. isitdns.net uses *.ns.cloudflare.com nameservers, which live in a different zone that can be resolved independently, so no glue is required here.

Missing glue, when it is required, makes the zone unresolvable from a cold cache while looking perfectly correct in every control panel.