DNS Denial Proof Report

A negative DNS answer must distinguish two different claims. NXDOMAIN says the queried name does not exist. NODATA says the name exists but has no record of the requested type. That difference affects troubleshooting, caching, and what must be proven by DNSSEC.

Unsigned DNS can return either claim, but a resolver cannot authenticate absence by signing an empty space. DNSSEC uses denial records to cover that space. NSEC links existing names in canonical order and lists the record types present at each owner. NSEC3 applies a salted, iterated SHA-1 hash before publishing comparable intervals, which makes casual zone enumeration harder but makes the proof more involved.

NXDOMAIN proof

Shows that the queried name falls inside a covered interval and that a matching wildcard cannot supply an answer.

NODATA proof

Shows an exact owner while demonstrating that its type bitmap excludes the requested record type.

Authenticated Data

The AD flag reports that the recursive resolver claims to have validated the answer.

Checking Disabled

A CD query asks the resolver to return data without enforcing normal validation, which is useful for diagnosis but not proof.

Negative answers are cached. An authority SOA record carries timing values used by recursive resolvers, so a repaired name may continue to appear absent until the cached negative entry expires. The effective negative-cache estimate is the smaller of the SOA record's TTL and its MINIMUM field when both are readable.

A recursive resolver report is still one vantage point. The resolver may omit authority records, filter an answer, serve cached data, or return SERVFAIL after a DNSSEC validation error. A CD comparison can reveal that split: SERVFAIL in the validating view beside NXDOMAIN or NODATA in the checking-disabled view is a validation conflict, not authenticated denial.

• Keep the queried name and record type together; NODATA is meaningless without the type.
• Keep the resolver and timestamp with the evidence because caches and policies change.
• For high-stakes conclusions, corroborate the recursive result with authoritative queries and independent DNSSEC validation.

How to Use This Tool:

Frame one precise DNS question before collecting evidence: one owner name, one record type, and one recursive resolver.

1. Enter a public hostname in Target name and choose the exact Record type whose presence or absence matters.
2. Leave Expected denial at Auto classify for investigation. Pin NXDOMAIN or NODATA only when the observed reply must be tested against a known expectation.
3. Select a Resolver view. Leave Proof family focus on automatic detection unless the zone is expected to use NSEC or NSEC3.
4. Enable CD-bypass comparison when SERVFAIL or a suspected DNSSEC-chain problem is part of the incident. Increase the timeout from the 4,500 ms default only for a known slow path.
5. Build the report, then read the conclusion and denial coverage before the retry guidance. A missing AD flag or incomplete proof must remain caveated even when the reply code is negative.

Interpreting Results:

Authenticated NXDOMAIN or Authenticated NODATA requires the matching negative reply, complete NSEC or NSEC3 coverage, and AD=true. Partial denial proof means relevant denial material was found but the complete required path was not established. Negative reply without complete denial records reports the resolver outcome without elevating it to a full proof.

Validation conflict is the most important comparison result: the validating lane returned SERVFAIL while the checking-disabled lane exposed NXDOMAIN or NODATA. Investigate DS, DNSKEY, and RRSIG continuity before citing the negative outcome. Other differing outcomes are reported as diverging views without assigning that specific cause.

The negative-cache estimate is a retry clue, not a promise that every resolver will refresh at the same moment. Keep the observed SOA context, then check authoritative DNS when deciding whether publication has changed.

Technical Details:

Denial interpretation starts with the response shape. A transport error is distinct from a DNS response. A non-empty answer is positive regardless of the header code. With zero answers, status 3 becomes NXDOMAIN and status 0 becomes NODATA; other status values retain their DNS response-code meaning.

Transformation Core

NSEC names are compared in canonical DNS order, from the rightmost label toward the left. An interval covers a target only when it falls strictly after the owner and strictly before the next name, with wraparound at the end of the canonical order. For NSEC3, the lowercase wire-format name is hashed with the record's salt and iteration count, encoded with Base32hex, and compared with the published hashed interval.

Rule Core

Proof strength and overall state follow ordered rules rather than a numeric pass threshold.

1. Strong denial proof requires NXDOMAIN or NODATA plus complete NSEC or NSEC3 coverage.
2. Partial denial proof requires a negative reply and some relevant exact-owner, interval, hash, or unsupported-NSEC3 evidence without complete coverage.
3. A negative reply with no adequate denial material remains Negative reply without complete denial records.
4. Any Fail finding makes the overall state Attention. With no Fail but at least one Review, the state is Review. Otherwise it is Supported.

NSEC3 checking supports hash algorithm 1 with a non-negative iteration count and a valid hexadecimal salt. Unsupported parameters are retained as partial evidence rather than treated as a complete proof.

Formula Core

The negative-cache estimate uses the smaller readable SOA value.

If either value is unreadable, no retry interval is inferred. Resolver latency is measured in whole milliseconds, while negative-cache timing is reported in seconds.

Evidence boundaries

AD is accepted as the selected resolver's claim; RRSIG chains are not validated locally. Authority records are interpreted from the recursive response, and the returned SOA owner is treated as observed zone context rather than the result of an authoritative trace.

Security and Privacy Notes:

The target name and record type are sent to the selected public DNS resolver. Enabling the CD comparison sends a second query for the same name and type with checking disabled. Resolver operators may log those queries under their own policies.

Do not use a recursive observation alone as forensic proof of authoritative zone contents. Preserve the resolver, time, response code, AD state, and authority records, then corroborate with direct authoritative and DNSSEC-chain evidence before making a security or ownership claim.

Worked Examples:

References:

• RFC 4034: Resource Records for DNS Security Extensions, RFC Editor, March 2005.
• RFC 4035: Protocol Modifications for DNS Security Extensions, RFC Editor, March 2005.
• RFC 5155: DNSSEC Hashed Authenticated Denial of Existence, RFC Editor, March 2008.
• RFC 2308: Negative Caching of DNS Queries, RFC Editor, March 1998.
• How to diagnose DNS lookup failures with dig, Simplified Guide.