| # | Check | Status | Evidence | Copy |
|---|---|---|---|---|
| {{ index + 1 }} |
{{ check.label }}
{{ check.rfc }}
|
{{ check.status }} | {{ check.note || '-' }} |
| # | Nameserver | A | AAAA | CNAME | Glue | Note | Copy |
|---|---|---|---|---|---|---|---|
| {{ index + 1 }} |
{{ row.ns }}
in-bailiwick
|
{{ row.a.join(', ') || '-' }} | {{ row.aaaa.join(', ') || '-' }} | {{ row.cname.join(', ') || '-' }} | {{ row.glueReady ? 'ready' : 'missing' }} | {{ row.note || '-' }} |
| Resolver | Status | NS code | Time | NS snapshot | SOA MNAME | SOA serial |
|---|---|---|---|---|---|---|
| {{ row.resolver }} | {{ row.status }} | {{ row.nsCode }} | {{ row.timeMs }} ms | {{ row.nsSnapshot || '-' }} | {{ row.soaMname || '-' }} | {{ row.soaSerial !== null ? row.soaSerial : '-' }} |
| Priority | Action | Why | Copy |
|---|---|---|---|
| {{ item.priority }} | {{ item.action }} | {{ item.why }} |
| SOA field | Value |
|---|---|
| {{ row.field }} | {{ row.value }} |
Nameserver delegation is the part of DNS that tells the rest of the internet which authoritative servers speak for a domain. When delegation is wrong, a provider migration or registrar change can look finished in one dashboard while real lookups still fail, drift, or point to the wrong place.
This checker turns that problem into a structured snapshot. It queries the domain's NS and SOA data through DNS over HTTPS, inspects each nameserver host for address and alias behavior, and then reports a top-level PASS, WARN, or FAIL together with a Health Board, a per-host Delegation Matrix, optional Resolver Drift evidence, an Action Plan, and machine-readable JSON.
That makes it useful before a DNS migration, after a registrar update, or whenever a domain resolves inconsistently and you want a fast delegation sanity check.
The tool looks at more than just the number of NS records. It checks whether in-bailiwick nameserver hosts have address glue, whether nameserver hostnames behave like canonical names instead of CNAME aliases, whether the SOA MNAME appears inside the NS set, and whether at least one host has IPv6 if dual-stack coverage matters to you.
A clean summary is still a recursive resolver view, not a full authoritative test from every network. Warnings often mean missing evidence or a deliberately skipped check. Failures are stronger signals, such as missing glue, aliased nameserver hosts, or a mismatch against the expected delegation set.
Start with the domain apex and keep the default Balanced profile unless you have a reason to demand a larger nameserver set. Balanced expects at least two NS records. Strict raises that expectation to three, so it is better as a policy check than as a first-pass triage mode.
Before you trust a healthy-looking headline, open the Delegation Matrix and confirm that each nameserver host actually has A or AAAA records and that any in-bailiwick host shows glue readiness. If those rows look wrong, the badge at the top is not enough.
The input path is more forgiving than the form label suggests. The code accepts a plain domain, but it also sanitizes URL-style and email-style input by extracting the hostname, lowercasing it, stripping leading and trailing dots, and converting it to ASCII before the first lookup.
Lookups run directly from the browser against recursive DNS over HTTPS endpoints. Cloudflare uses https://cloudflare-dns.com/dns-query, Google uses https://dns.google/resolve, and the package requests JSON responses with Accept: application/dns-json. Each probe records DNS status, elapsed time, answer data, and DNSSEC-related flags. When DNSSEC DO flag is enabled, the request adds do=1 and the package later checks whether an AD signal was seen in the resolver responses.
The first round queries NS and SOA for the normalized domain. The resulting NS hostnames are sorted, then each host is queried for A and AAAA, with optional CNAME checks when that switch is enabled. If Compare resolvers is on, the package repeats the NS and SOA stage against both resolvers and compares their snapshots for drift.
The main outputs are rule-based rather than formula-based. The package assembles a check list, assigns each row a status, and then rolls the headline label up to the most severe result.
| Check | Package rule | Typical outcome |
|---|---|---|
| NS count | Balanced targets at least 2 NS records. Strict targets at least 3. Counts above 7 warn. | FAIL at 0, WARN below target or above 7, PASS otherwise. |
| SOA serial present | Parses the SOA answer and looks for a numeric serial. | PASS when parsed, WARN when missing or unreadable. |
| SOA MNAME appears in NS set | Compares the SOA MNAME hostname with the observed NS host list. | PASS on match, WARN otherwise. |
| Nameserver hosts are canonical | Optional CNAME probe on each NS host. | FAIL if any CNAME answer appears, WARN if the check is disabled. |
| In-bailiwick glue readiness | For nameserver hosts under the same domain, requires address evidence. | FAIL if any in-bailiwick host lacks A and AAAA, PASS otherwise. |
| Nameserver host address reachability | Checks whether each NS host has at least one A or AAAA answer. | WARN if any host returns neither record type. |
| IPv6 nameserver coverage | Looks for at least one AAAA record across the NS host set. | PASS with AAAA present, WARN if absent, or FAIL if IPv6 is required. |
| Resolver agreement | Compares NS and SOA snapshots when both resolvers are queried. | PASS on match, WARN on mismatch or when comparison is disabled. |
| Expected NS alignment | Compares the observed NS set against the optional expected list. | FAIL when expected hosts are missing, WARN for unexpected extras. |
| DNSSEC AD evidence | Enabled only when the DO flag switch is on. | PASS if AD appears in a resolver response, WARN otherwise. |
| Field | Meaning | Type | Where it appears |
|---|---|---|---|
| domainASCII | Normalized hostname used for queries | string | Summary and JSON |
| SOA MNAME | Primary nameserver field from the SOA answer | hostname | Summary, Health Board, JSON |
| Serial | SOA serial number if parsed | integer | Summary, Health Board, JSON |
| GlueReady | Whether an NS host has address evidence | boolean | Delegation Matrix and JSON |
| Status | Outcome category for one rule | PASS, WARN, FAIL | Health Board and Action Plan |
This bundle contains no package-specific backend code for the check itself. The browser talks directly to Cloudflare or Google, and the current form state is also written into the page URL through query parameters. The top-level health label is intentionally conservative: one failure makes the whole run FAIL, and any remaining warning keeps it at WARN.
The quickest useful run takes only a few fields.
The headline label is a severity roll-up, not an average. One failed check makes the whole run FAIL. If there are no failures but at least one warning, the run stays at WARN. That means a functioning domain can still show a yellow result because you skipped resolver comparison or because the nameserver set lacks AAAA records.
Do not overread a single recursive snapshot. Verification is strongest when the Health Board, Delegation Matrix, and Resolver Drift all tell the same story. When they do not, follow the Action Plan and confirm with authoritative DNS checks before making registrar or provider changes.
Take a domain delegated to two out-of-bailiwick hosts such as ns1.provider.net and ns2.provider.net. Both return A and AAAA records, the SOA MNAME matches one of those hosts, and Compare resolvers is enabled so both resolvers return the same NS and SOA snapshot.
The result can reach PASS because the Health Board shows the expected NS count, no alias problem, matching resolver evidence, and IPv6 presence. The Delegation Matrix then works as a quick sanity check rather than the place where the bad news appears.
Imagine the same domain has exactly two nameservers. In Balanced, the row NS count (target >= 2) passes. Switch to Strict, and the target becomes 3 instead.
The delegation may still resolve correctly, but the same evidence now produces a warning. The package is telling you the setup is leaner than the stricter standard, not that the zone is automatically broken.
Suppose a domain delegates to ns1.example.com and ns2.example.com, and those hosts are inside the same domain. If ns1.example.com returns no A or AAAA data, the Delegation Matrix shows GlueReady as false for that row.
The Health Board then marks In-bailiwick glue readiness as FAIL, and the Action Plan tells you to publish A or AAAA glue for the affected nameserver host. That is the kind of failure worth fixing before you depend on the delegation in production.
No. It means the evaluated checks passed for the resolver evidence the package collected. Different resolvers or caches can still disagree, especially during recent changes.
Warnings can come from disabled resolver comparison, missing IPv6, a stricter NS-count policy, or softer consistency checks such as SOA MNAME mismatch. The domain may still resolve while one of those conditions needs review.
No. The package queries recursive DNS over HTTPS resolvers, then inspects the returned data. That is why resolver choice and resolver comparison affect interpretation.
The bundle contains no package-specific server path for this check. The browser sends requests directly to Cloudflare or Google. The current form state is also reflected in the page URL so links can preserve settings.