// INTERACTIVE EVIDENCE COMPARISON LAB & SAMPLE-REPORT VIEWER · v1.1

Evidence-Preserving DNS Diagnostics vs. Naive Error Collapse

Browser-based DNS-over-HTTPS (DoH) scanners frequently collapse transport timeouts, HTTP 5xx errors, and DNS SERVFAIL (Status 2) responses into empty arrays ([]) — turning temporary resolver failures into false 0/100 missing-record findings. Use the interactive lab below to inspect how FaultyPacket's live scanners preserve full evidence state across every lookup.

← Run Live NIS2 & DORA Supplier Posture Auditor View Full Sample Board Audit Report → Open Main Domain & Email Scanner →

// CONTROLLED EVIDENCE LAB & SAMPLE-REPORT VIEWER (v1.1) · ZERO LIVE NETWORK CALLS

Animated Evidence Lab: Why Transport Errors Must Never Become Missing-Record Findings

Select any of the 4 controlled DNS-over-HTTPS fixtures below to step through 1. Request → 2. Response → 3. Interpretation → 4. Report. This demonstrates how FaultyPacket's evidence-aware DoH engine separates transport/resolver failures (Timeout / SERVFAIL / NXDOMAIN) from genuine missing records (Status: 0 with empty Answer).

1. RequestDoH query sent

2. ResponseTransport or DNS RCODE

3. InterpretationEvidence state classification

4. Report OutputCustomer-facing wording

Naive Lookup Pattern (Error Collapsed to []) FALSE MISSING FINDING

1. Request

GET /dns-query?name=_dmarc.supplier-example.co.uk&type=TXT

2. Raw Response

fetch() rejected: AbortError / network timeout after 5000ms

3. Helper Return Value

catch(e) { return []; } // Collapses transport failure into empty list

4. Resulting Report Row

Score: 0/100 · Status: MISSING (_dmarc) · Action: 30-DAY NOTICE (Overstates evidence)

FaultyPacket Evidence-Preserving Pattern (Live) EVIDENCE SEPARATED

1. Request

GET /dns-query?name=_dmarc.supplier-example.co.uk&type=TXT (Cloudflare + Google DoH fallback)

2. Raw Response

Both resolvers failed or timed out: AbortError / network timeout

3. Structured Evidence State

{ state: "error", reason: "network/fetch failure", records: [] }

4. Resulting Report Row

Score: UNASSESSED · Status: EVIDENCE UNAVAILABLE (Lookup failed — retry) · Action: RETRY LOOKUP

// SAMPLE-REPORT EVIDENCE BOUNDARY VIEWER · OBSERVED VS. INTERPRETATION VS. NOT ESTABLISHED

How Every FaultyPacket Audit Card Separates Public Observation from Internal Assurance

Every finding in our sample reports and Python CLI auditors explicitly distinguishes what was observed publicly, how it is interpreted, and what cannot be established without authenticated internal review:

DMARC Policy Published at Monitoring Only (p=none) OBSERVED WEAKNESS

Observed (Public DNS TXT)_dmarc.example.co.uk TXT "v=DMARC1; p=none; rua=mailto:[email protected]" (DNS Status: 0 NOERROR).

Technical InterpretationAggregate reports are requested, but unauthenticated messages failing SPF/DKIM alignment are not quarantined or rejected by receiving gateways under DMARC policy.

Not Established by Public LookupDoes not prove whether downstream mail gateways apply custom inbound anti-spoofing rules or whether all third-party senders have completed DKIM onboarding.

DNS Lookup Failure / Resolver SERVFAIL on _mta-sts EVIDENCE UNAVAILABLE

Observed (DoH Transport / RCODE)DNS response returned Status: 2 (SERVFAIL) or timed out across primary and fallback DoH resolvers.

Technical InterpretationMarked UNASSESSED — LOOKUP FAILED, RETRY. No compliance deduction or 0/100 score is assigned until an authoritative Status: 0 response is obtained.

Not Established by Public LookupNeither the presence nor the absence of _mta-sts is established during a resolver failure.