| # | Nameserver | In-bailiwick | Glue required | A | AAAA | CNAME | Notes | |
|---|---|---|---|---|---|---|---|---|
| {{ idx + 1 }} | {{ row.ns }} | {{ row.inBailiwick ? 'Yes' : 'No' }} | {{ row.glueRequired ? 'Yes' : 'No' }} | {{ row.a.join(', ') || '-' }} | {{ row.aaaa.join(', ') || '-' }} | {{ row.cname.join(', ') || '-' }} | {{ row.note || '-' }} |
| # | Check | Status | Notes | |
|---|---|---|---|---|
| {{ idx + 1 }} | {{ c.label }} | {{ c.status }} | {{ c.note || '-' }} |
| # | Parent nameserver | A | AAAA |
|---|---|---|---|
| {{ idx + 1 }} | {{ row.ns }} | {{ row.a.join(', ') || '-' }} | {{ row.aaaa.join(', ') || '-' }} |
| Resolver | Status | Code | Time | NS Snapshot |
|---|---|---|---|---|
| {{ e.resolver }} | {{ e.status }} | {{ e.code }} | {{ e.timeMs }} ms | {{ e.nsSnapshot || '-' }} |
DNS delegation is the handoff that tells the rest of the internet which nameservers answer for a domain. When that handoff is incomplete, especially after a registrar change or provider migration, a zone can appear correct in one control panel while real lookups still fail or vary by resolver.
This checker turns that handoff into a readable audit. It normalizes the entered domain, queries the published nameserver set through DNS over HTTPS, expands each nameserver host into A and AAAA data, and then shows where glue is implied, where address data is missing, and where resolver views disagree.
The result is not a single yes or no verdict. Instead, the summary counts how many checks passed, warned, or failed, then breaks the evidence into a delegation table, a rules table, optional parent-zone context, optional cross-resolver evidence, and a structured JSON export.
That makes the package useful in a few common situations: checking whether an in-bailiwick nameserver renumbering is visible yet, verifying that a newly delegated subdomain has reachable nameserver hosts, or comparing Cloudflare and Google after a recent DNS change when caches may still be out of sync.
The tool is intentionally conservative about what it can prove. It sees the world through recursive resolver JSON APIs in the browser, not by talking directly to the parent authoritative servers, so it can strongly suggest glue trouble without claiming to be the parent zone itself.
Start with the delegated domain name itself, not a full hostname below it. The input sanitizer is forgiving and can pull a hostname out of a URL or email-style string, but the most useful run still comes from entering the zone you actually want to audit.
The first screen answers the question most operators care about: which nameservers were returned, are any of them inside the same domain, and do those in-bailiwick hosts have address data right now. If an in-bailiwick nameserver row shows no A or AAAA values, that is the strongest signal in the package because recursive resolvers need parent-side glue to break the dependency loop.
The advanced switches let you decide how much confidence you want from one run. Compare resolvers asks both Cloudflare and Google for the NS set so you can see whether propagation or cache state differs. Check CNAME on NS asks whether a nameserver hostname resolves as an alias instead of a canonical target. Check DS records looks for a Delegation Signer record at the delegation point so you can tell whether DNSSEC delegation is visible.
The code first strips the input down to a hostname, removes leading and trailing dots, lowercases it, and converts it to an ASCII form suitable for DNS lookups. From there it derives a simple parent candidate by dropping the leftmost label, which becomes the basis for the optional parent-context lookup.
Resolver traffic goes directly from the browser to one of two DNS over HTTPS JSON endpoints: Cloudflare or Google. Requests are issued as HTTP GETs with name and type parameters, an Accept: application/dns-json header, and a per-request timeout if you set one. Nameserver host expansion runs in parallel with a configurable worker count from 1 to 16.
Each nameserver row carries the actual hostname returned in the NS answer, a flag for whether that hostname is in-bailiwick, an inferred Glue required flag that mirrors the in-bailiwick check, any A or AAAA answers seen through the selected resolver path, any optional CNAME answers, and a notes field that calls out missing address data or alias behavior.
The package then derives a compact rule set from those rows. Some rules are hard failures, such as an in-bailiwick nameserver host with no A or AAAA data, while others are advisory, such as missing DS data or disagreement between recursive resolvers.
| Check | What the package looks for | Typical meaning |
|---|---|---|
| At least 2 NS records | Counts the unique NS hostnames returned for the domain. | One nameserver warns, none fails, two or more pass. |
| In-bailiwick NS have A/AAAA | Looks only at nameserver hosts that equal the domain or end in .domain. |
Missing address data fails because glue would normally be needed. |
| NS hostnames are canonical | Optional CNAME query for each nameserver host. | CNAME answers fail, disabled checking warns. |
| Nameserver hostnames resolve | Checks whether each nameserver host has any A or AAAA answer. | Missing address data warns even for out-of-bailiwick hosts. |
| DS record published | Optional DS query at the delegation point. | Presence passes, absence warns, disabled checking omits the rule. |
| Resolver agreement | Compares the sorted NS snapshots returned by Cloudflare and Google. | Mismatch warns because caches or upstream data differ. |
| Parent-zone glue certainty | Always emitted as a warning note. | Reminds you that recursive JSON responses are indirect evidence, not the parent referral itself. |
That last warning is important. RFC 9471 clarifies what authoritative servers are expected to include in referral responses for in-domain nameservers, but this browser package does not capture raw parent referrals. It queries recursive resolvers after they have already interpreted the zone data, which is excellent for troubleshooting the user-visible outcome but weaker for proving what the parent actually returned on the wire.
There is no package-specific backend for the audit itself. The domain you enter is sent from your browser to the chosen DNS over HTTPS provider, and the current form state is mirrored into the page URL by the shared query-parameter mixin so runs can be reloaded or shared. That is convenient for troubleshooting, but it also means the checked domain and options should be treated as operational data.
The summary counts are meant to be read as evidence buckets, not as a single overall grade. A run can show several passes and still matter because one failure points to a concrete delegation flaw. It can also show only warnings because the domain is unsigned, resolver comparison was disabled, or the package is reminding you that it inferred glue need indirectly.
The strongest pattern is consistency across tabs. When the delegation row, the rule note, and the resolver evidence all point in the same direction, you usually have enough confidence to move on to a registrar or DNS host fix. When they do not, take the package output as a triage lead and confirm from authoritative infrastructure.
Suppose a domain publishes ns1.provider.net and ns2.provider.net as its nameserver set. Both nameserver hosts return A or AAAA data, neither hostname is inside the delegated domain, and the optional CNAME check comes back empty.
In that case the package usually shows passes for the NS count, for canonical nameserver targets, and for nameserver hostname resolution. If DS checking is enabled and the zone is unsigned, you may still see a warning there, plus the permanent warning that parent-zone glue certainty is inferred rather than directly observed.
Now imagine the NS answer contains ns1.example.com and ns2.provider.net for the domain example.com. The first nameserver is in-bailiwick, so the package marks Glue required as yes for that row. If neither A nor AAAA data is visible for ns1.example.com, the row note calls it out as likely glue breakage.
The Checks tab then fails In-bailiwick NS have A/AAAA, while At least 2 NS records may still pass. That mixed result is normal: the domain has enough listed nameservers, but one of the listed hosts is not practically reachable through the resolver view being tested.
No. The code queries recursive DNS over HTTPS resolvers and evaluates the answers they return. That is why the package includes an explicit warning about parent-zone certainty.
NS targets are expected to be canonical hostnames with address data of their own. Aliasing adds indirection and can break the additional address data that resolvers expect during delegation handling, so the package treats returned CNAME answers as a failure.
Not by itself. It means the package did not see DS data at the delegation point. Unsigned zones commonly show that warning.
It queries Cloudflare first and only falls back to Google when the first request fails in a way the code treats as a network problem. It does not average or merge the two answers unless you explicitly enable resolver comparison.
Yes. The package can copy or download CSV from the tables, export DOCX reports for each evidence view, and save the structured JSON payload for later inspection.