DNS Denial Proof Report

Denial Proof Brief

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.

Current inputs differ from the last completed run. Re-run the report before trusting the denial read.

Target name:

Inspect one hostname or URL and build a resolver-view denial evidence report.

Record type:

Choose the RR type whose absence must be proven.

Proof target:

Let the live reply decide, or score it against an expected NXDOMAIN or NODATA shape.

Resolver view:

Select the recursive DNS-over-HTTPS view to cite in the evidence ledger.

Proof family focus:

Keep auto detection unless you need to flag an expected NSEC or NSEC3 family.

CD-bypass comparison:

Compare the validating lane with a checking-disabled lane.

Timeout:

Limit each resolver request before the run is marked as a transport issue.

Brief item	Read	Operator action	Copy row
{{ row.item }}	{{ row.read }}	{{ row.action }}

Lens	Query	Outcome	Authority	Timing	Copy row
{{ row.lens }}	{{ row.query }}	{{ row.outcome }} {{ row.outcomeNote }}	{{ row.authority }}	{{ row.timing }}

Check	Status	Read	Why it matters	Copy row
{{ row.check }}	{{ row.status }}	{{ row.read }}	{{ row.impact }}

Timer	Value	Source	Next move	Copy row
{{ row.timer }}	{{ row.value }}	{{ row.source }}	{{ row.nextMove }}

Export to PDF Fullscreen

Include query parameters

Embed:

Customize embed code

Include query parameters

Wrap embed in collapsible toggle

Collapse panel by default

Hide card frame (bare iframe)

Loading behavior

Width

Height

Aspect ratio (width : height)

Max height (optional)

Collapsible heading

Collapsible description (optional)

Allow fullscreen

Referrer policy

Sandbox tokens

DNS denial evidence explains why a resolver believes a name or record type is absent. NXDOMAIN means the owner name does not exist. NODATA means the owner name exists, but not with the requested record type. DNSSEC can support those answers with NSEC or NSEC3 records from the authority section.

Operational denial proof is different from a plain empty lookup. A useful report preserves the queried name, record type, resolver view, AD and CD behavior, authority records, SOA timing, and the exact checks that were strong, partial, or missing.

DNS denial proof flow from query to evidence and retry timing

A recursive resolver view is still only one view. Stronger incident evidence may require authoritative packet captures, independent validating resolvers, and signer or DS/DNSKEY investigation when validation behavior is inconsistent.

Technical Details:

The report sends a validating DNS-over-HTTPS query with the DNSSEC OK flag and can optionally send a second checking-disabled lane. It parses answer and authority sections, detects SOA, RRSIG, NSEC, and NSEC3 records, classifies the reply shape, and records latency and negative-cache timing.

DNS denial proof checks
Evidence check	Strong signal	Why it matters
Reply shape	`NXDOMAIN` or `NOERROR / no data`	Confirms the result is a denial rather than an answer.
AD flag	Validated lane returns AD=true	Shows the resolver treated the negative answer as authenticated.
NSEC NODATA	Exact owner NSEC lacks the requested type	Proves an existing owner does not have that RR type.
NSEC NXDOMAIN	QName and wildcard-source intervals covered	Shows the owner and wildcard source were absent.
NSEC3 NXDOMAIN	Closest encloser, next closer, and wildcard denial checks	Supports hashed denial reasoning.

Negative-cache timing is derived from SOA evidence when available, using the returned SOA TTL and SOA minimum. NSEC3 hashing uses SHA-1 with the returned salt and iteration count when the parameters are supported. The tool interprets records and resolver flags in-browser; it does not perform a full cryptographic validation of signatures.

Everyday Use & Decision Guide:

Use this report when a missing record matters enough to cite. Enter the hostname or URL, select the exact record type, and choose whether you expected NXDOMAIN, NODATA, or want auto classification.

Use CD-bypass comparison when SERVFAIL might be a validation problem rather than a true denial.
Use NSEC focus or NSEC3 focus only when you expect a specific denial family.
Preserve Evidence Ledger with the Proof Brief so the conclusion remains traceable.
Use Retry Window before rechecking a recently changed negative record.

Do not claim full denial proof when the authority section has no NSEC or NSEC3 material. In that case, the report can describe an empty recursive reply but not a complete DNSSEC denial trail.

Step-by-Step Guide:

Enter a hostname, FQDN, or URL. The host is normalized before lookup.
Select the record type whose absence matters, such as A, TXT, CAA, or DS.
Set Proof target to auto, NXDOMAIN, or NODATA.
Choose resolver, denial family focus, CD-bypass comparison, and timeout.
Build the report and read Proof Checks before relying on the summary claim.
Use Retry Window and exported evidence when DNS state may change later.

Interpreting Results:

Complete proof strength means the returned evidence satisfied the relevant denial checks for the observed reply family. Partial means useful evidence exists but one or more checks are missing. Empty or answer-present outcomes should be read as operational observations, not full denial proofs.

A validation split is important. If the validating lane fails while the CD-bypass lane returns a denial, investigate DNSSEC chain continuity before citing the denial itself.

Worked Examples:

NXDOMAIN. A missing host under a signed NSEC zone should show a negative reply, authority SOA, and interval coverage for the queried name plus wildcard-source denial.

NODATA. A name that exists with AAAA but no MX should return NOERROR with no MX answers. An exact-owner NSEC record whose bitmap lacks MX is the useful proof.

Validation conflict. If the normal lane returns SERVFAIL and CD-bypass returns NSEC3 denial material, the next step is DS, DNSKEY, and signature investigation, not a simple absence claim.

FAQ:

What is the difference between NXDOMAIN and NODATA?

NXDOMAIN says the owner name is absent. NODATA says the owner exists but lacks the requested record type.

Does the report validate DNSSEC signatures locally?

No. It interprets resolver AD/CD behavior and returned DNSSEC records. Use authoritative validation tools for cryptographic proof.

Why include SOA timing?

SOA minimum and TTL help estimate how long a negative answer may stay cached before a changed record is expected to appear.

Glossary:

NXDOMAIN: A DNS response code meaning the queried owner name does not exist.
NODATA: A NOERROR reply with no records of the requested type.
NSEC: A DNSSEC record that proves absence by naming the next owner and existing types.
NSEC3: A hashed form of authenticated denial evidence.