{{ denialSummaryHeading }}
{{ summaryFigure }}
{{ summaryLine }}
{{ badge.label }}
{{ node.label }}
{{ stageText }}
Current inputs differ from the last completed run. Re-run the report before trusting the denial read.
{{ normalizationNote }}
Report built for the current resolver view. Review the proof tabs below before citing the denial read.
Inspect one negative DNS reply at a time, separate validating and CD-bypass views, and turn the authority section into an operator-readable proof trail with NSEC or NSEC3 notes, SOA retry timing, and scope-limited caveats.
Enter one hostname, FQDN, or URL; the lookup uses the normalized host.
Pick A, TXT, CAA, DS, or another supported type for the absence claim.
Use Auto for triage, or choose NXDOMAIN/NODATA when you know the intended outcome.
Keep one resolver view per report so the evidence ledger stays traceable.
Leave Auto unless the zone should prove denial with NSEC or NSEC3.
Turn on when SERVFAIL, AD changes, or DNSSEC chain issues may hide denial evidence.
{{ include_cdBool ? 'On' : 'Off' }}
Choose 3000-9000 ms per request; longer waits reduce false transport errors.
Run the report to populate the Proof Brief, Evidence Ledger, Proof Checks, Denial Signal Map, Retry Window, and JSON artifacts.
Tags: DNS, Diagnostics, Networking, Security
DNS Configuration Report Audit a domain's public DNS records, compare resolver snapshots, and spot missing authority, mail, address, policy, TTL, or timing risks.
Nameserver Health Check Check a domain's nameserver health with resolver comparison, glue readiness, public-address checks, SOA timers, and repair cues.
MX Record Lookup Look up a domain's MX records, compare public resolver answers, and flag Null MX conflicts, unresolved hosts, CNAME targets, and mail-policy clues.
DNSSEC Validator Validate a domain's DNSSEC chain with DNSKEY, DS, RRSIG, resolver AD comparison, signature timing checks, and a pass-rate report.
Customize
Advanced
:

A negative DNS answer is not just an empty table. It can mean that the owner name does not exist, that the name exists but the requested record type is absent, that DNSSEC validation failed before a usable answer could be trusted, or that a recursive cache is still carrying an older view. A useful denial proof keeps those cases separate and ties the conclusion to the exact name, record type, resolver, and time of observation.

The main distinction is between NXDOMAIN and NODATA. NXDOMAIN is a name error: the queried owner name is absent in the resolver's current DNS view. NODATA is type-specific absence: the owner name exists, but the requested RR type is not present. That difference matters for CAA checks, DS delegation work, mail cutovers, and incident notes because the corrective action changes with the shape of the absence.

NXDOMAIN
The owner name itself was not found.
NODATA
The owner name was found, but the selected record type was absent.
NSEC
Clear-name DNSSEC denial records that can show missing names or missing type bits.
NSEC3
Hashed DNSSEC denial records that hide owner names while still supporting absence checks.
Name + type host / A, TXT, DS Negative reply NXDOMAIN or NODATA NSEC / NSEC3 absence evidence SOA timing retry window Authenticated denial evidence path A strong conclusion keeps the resolver view, AD state, denial family, wildcard caveat, and cache timing together.

DNSSEC turns some negative answers into evidence that can be checked. With NSEC, the proof may include a clear owner name, a next-domain interval, and a type bitmap. With NSEC3, comparable facts are hidden behind hashes, so the reasoning depends on closest-encloser, next-closer, and wildcard denial checks. NSEC3 opt-out and unsupported parameters can weaken what the evidence proves, especially around delegation boundaries.

Time is part of the proof. Recursive resolvers cache negative answers, and the retry period is normally framed by SOA data in the authority section. After a record is removed or added, two honest resolver views can disagree because one cache has expired and another has not. A checking-disabled comparison can also expose a different lane when normal validation returns SERVFAIL.

A denial proof is strongest when the response code, requested type, AD signal, NSEC or NSEC3 material, wildcard check, and SOA timing all support the same conclusion. It is weaker when the resolver strips authority records, the proof family is missing, validation lanes split, or the result needs independent authoritative evidence for legal, registry, or post-incident use.

How to Use This Tool:

Use one target name and one record type per run so the proof brief stays narrow enough to cite.

  1. Enter one Target name. A hostname, fully qualified domain name, URL, or email-like value is normalized to the host; extra lines are ignored so the report stays tied to one target.
  2. Choose the Record type whose absence matters. Supported choices are A, AAAA, CNAME, MX, TXT, NS, CAA, and DS.
  3. Leave Proof target on Auto classify for triage, or choose NXDOMAIN proof or NODATA proof when you already know which denial shape should appear.
  4. Open Advanced when the resolver or DNSSEC lane matters. The default resolver is Google Public DNS; Cloudflare and DNS.SB are available for separate public views.
  5. Keep Proof family focus on Auto detect unless you expect NSEC or NSEC3 and want mismatch notes. Leave CD-bypass comparison on when SERVFAIL, AD changes, or DNSSEC chain issues may hide the underlying denial response.
  6. Adjust Timeout only when slow resolver paths are being mistaken for transport failures. The visible choices are 3000, 4500, 6500, and 9000 ms per request.
  7. Select Build report. If the name is empty, malformed, or not a supported DNS name, fix Target name before trusting any conclusion.
  8. Read Proof Brief first, then use Evidence Ledger, Proof Checks, Denial Signal Map, Retry Window, and JSON to preserve or review the supporting details.

When the inputs change after a run, rebuild the report before citing it. The warning about changed inputs means the visible evidence no longer matches the current controls.

Interpreting Results:

Start with the summary conclusion, but verify it against Proof Checks. Authenticated NXDOMAIN supports a missing-name conclusion for the selected resolver view. Authenticated NODATA supports a missing-record-type conclusion for a name that still exists. Answer present means the selected RR type returned data, so the run is not a denial proof.

Proof Checks is where false confidence usually shows up. A negative response code alone is not enough. Check the AD flag, authority SOA, denial family, NSEC or NSEC3 coverage, wildcard denial, validation split, and requested-family focus before using strong wording in a ticket, incident note, or audit handoff.

Strong denial proof means the returned evidence supports the absence pattern the run could inspect. Partial denial proof means useful material was present but one or more checks need caveats. Negative reply without denial records may still explain what a resolver returned, but it should not be quoted as a complete DNSSEC denial trail.

Use Retry Window when recent DNS changes are involved. If a negative-cache retry value is visible, wait roughly that long before expecting recursive caches to forget the old absence. If validating and CD-bypass views split, preserve both lanes and inspect DS, DNSKEY, RRSIG, and authoritative responses before deciding the final cause.

Technical Details:

DNS denial proof depends on the tuple being tested. NXDOMAIN applies to the owner name. NODATA applies to the owner name, DNS class, and requested RR type. DNSSEC adds signed denial records so a signed zone can show why a matching RRset was absent instead of leaving the resolver with only an empty answer section.

NSEC and NSEC3 use different evidence shapes. NSEC uses canonical DNS name order and type bitmaps. NSEC3 hashes owner names with the returned salt and iteration count, then compares the resulting base32hex hashes against returned owner and next-hash spans. The report treats unsupported NSEC3 hash algorithms as partial evidence rather than pretending the proof was fully checked.

Rule Core:

Signal Supports Important caveat
NXDOMAIN with signed denial material The queried owner name is absent in the resolver's view. Wildcard-source denial still matters because a wildcard could otherwise synthesize an answer.
NODATA with matching owner and missing type bit The name exists, but the selected RR type is absent. CNAME and wildcard cases can change how the absence must be proven.
NSEC owner, next-domain interval, and type bitmap Clear-name proof for a missing owner name or missing RR type. Coverage follows canonical DNS name order, not ordinary alphabetic intuition.
NSEC3 owner hash, salt, iterations, and next-hash span Hashed proof using closest-encloser, next-closer, and wildcard checks. Opt-out and unsupported hash algorithms weaken the conclusion.
AD flag present in the validating view The recursive resolver claims the relevant response authenticated. AD is a resolver signal, not an independent local signature-validation transcript.
CD-bypass view differs from the validating view Validation policy or a broken DNSSEC chain may be the user-visible failure. The checking-disabled lane is diagnostic evidence, not a trust claim.

Transformation Core:

Proof family NODATA path NXDOMAIN path
NSEC Find an exact NSEC owner matching the queried name and verify the selected type is absent from the bitmap. Find an NSEC interval covering the queried name and a wildcard-source denial covering the possible wildcard owner.
NSEC3 Hash the queried name with the returned salt and iterations, then check the matching owner hash and type bitmap when available. Hash the closest encloser, next closer, and wildcard candidate, then compare those hashes with returned NSEC3 spans.
No denial family The resolver may still show an empty answer for the selected type. The resolver may still show a name error.

Negative Cache Formula:

When SOA data is visible, the retry estimate follows the DNS negative caching rule that uses the smaller of the SOA minimum field and the SOA record TTL.

Tneg = min ( TSOA-minimum , TSOA-TTL )

For example, if a negative response carries an SOA minimum of 900 seconds and the SOA record TTL is 300 seconds, the retry estimate is 300 seconds. If no readable SOA record is visible in the collected lanes, the cache window should not be inferred from the denial result alone.

A resolver-observed report is deliberately narrower than an authoritative DNSSEC trace. It records the selected public resolver's status code, answer and authority records, AD state, optional CD-bypass lane, proof checks, and SOA timing. Independent proof still requires authoritative responses and full signature validation when the result has compliance, legal, or registry weight.

Security and Privacy Notes:

The target name, selected record type, resolver choice, DNSSEC flags, and timeout setting are used to make DNS-over-HTTPS requests to the selected public resolver. Returned DNS data is analyzed in the browser for the report. Do not submit hostnames that reveal confidential investigations, internal project names, or unannounced infrastructure unless that resolver view is acceptable for your organization.

  • The report interprets returned records and the resolver AD flag. It does not independently validate RRSIG chains locally.
  • Resolver caches, filtering, stripped authority records, and transport failures can all limit what the report can prove.
  • For final audit proof, preserve authoritative server responses, DNS provider change logs, timestamps, and packet captures alongside this resolver-view report.

Worked Examples:

Removed web host

Enter old-app.example.com, choose A, and set Proof target to NXDOMAIN proof. If Proof Brief reads Authenticated NXDOMAIN and Proof Checks pass reply shape, denial family, interval coverage, and wildcard denial, the incident note can say that this resolver observed the host name as absent.

Unsigned child delegation check

Enter child.example.com, choose DS, and leave Proof target on Auto classify. An Authenticated NODATA result can support a deliberate unsigned-delegation read, but an NSEC3 opt-out warning means the DS conclusion should be checked against the parent zone before a final DNSSEC handoff.

Validation failure during a rollover

Keep CD-bypass comparison on and query the failing name. If the validating view shows SERVFAIL while the CD-bypass lane returns NODATA or NXDOMAIN, preserve Evidence Ledger and inspect DS, DNSKEY, and RRSIG continuity before treating the negative answer as clean denial evidence.

Recent record removal

After deleting a TXT record, choose TXT and read Retry Window. A negative-cache retry value of 15 minutes means another recursive resolver may continue returning the older view until its cache expires.

Advanced Tips:

  • Keep Resolver view fixed when comparing repeated runs. A resolver change is useful evidence only when you want to show that public recursive views disagree.
  • Use NXDOMAIN proof or NODATA proof when you have an expected result. A failed expected-target check catches tests where the wrong denial shape came back.
  • Leave CD-bypass comparison on during DNSSEC incidents. A validating SERVFAIL with a checking-disabled negative answer points toward chain validation rather than ordinary absence.
  • Set Proof family focus only when the zone should use NSEC or NSEC3. A mismatch note is useful during signer migrations or when a provider changed denial style.
  • Use Retry Window before rechecking recent removals. A visible negative-cache value gives the earliest reasonable time to expect a changed absence result to age out naturally.

FAQ:

Why does the same name sometimes produce NXDOMAIN in one run and NODATA in another?

NXDOMAIN depends on the owner name, while NODATA depends on the owner name plus the selected record type. Recheck Record type, the normalization note, Resolver view, and Evidence Ledger before comparing two runs.

Does AD yes mean the proof is complete?

No. AD yes means the selected recursive resolver claims the relevant data authenticated. Still read Proof Checks for NSEC or NSEC3 coverage, wildcard denial, and any validation split.

Why should CD-bypass comparison stay enabled?

It helps identify cases where normal validation returns SERVFAIL but the checking-disabled lane exposes the underlying response. That difference points toward DNSSEC chain troubleshooting rather than a simple missing-record conclusion.

What should I do when the target name is invalid?

Use one hostname or URL, remove spaces and unsupported characters, and make sure the normalized host has at least two DNS labels. Extra lines are ignored so the report stays tied to one target.

Can I use the report as final audit proof?

Use it as resolver-view evidence. For final audit proof, add authoritative server responses, DNS provider timestamps, and a full DNSSEC validation trace when the conclusion needs independent verification.

Glossary:

AD
Authenticated Data, a resolver flag indicating that the resolver claims the relevant response data authenticated.
CD
Checking Disabled, a DNSSEC flag used to request data without normal recursive validation enforcement.
NODATA
A negative DNS answer where the owner name exists but the requested RR type is absent.
NSEC
A DNSSEC denial record that uses clear owner names, next-domain spans, and type bitmaps.
NSEC3
A DNSSEC denial record that uses hashed owner names, salt, iterations, and hash spans.
NXDOMAIN
A DNS name error indicating that the queried owner name does not exist.
SOA
Start of Authority, the zone record that can carry timing data used for negative caching.

References: