DNSSEC modes

Back to Web Dig

What DNSSEC does

DNSSEC uses public-key signatures to authenticate DNS records and denial proofs. It helps detect forged or modified DNS answers. It does not encrypt DNS; DNS-over-HTTPS (DoH) encrypts the connection to the selected resolver.

This demo offers two different trust models. The raw DNS response is always shown so you can inspect flags, signatures, and records. When DNSSEC is enabled, its status and any validation error appear at the bottom with the response metadata. A DNSSEC issue badge appears alongside the elapsed query time.

Choose a mode

Off

Sends a normal query without requesting DNSSEC records. No DNSSEC status is inferred from the answer.

Trust upstream (AD)

Requests DNSSEC data and reads the resolver's AD (Authenticated Data) flag. In this app the resolver is reached over HTTPS, so the flag is protected in transit. This is still the resolver's validation claim: rustdns does not independently verify the signatures in this mode.

  • AD=1 / Secure: the resolver asserts that it validated the answer.
  • AD=0 / Insecure indication: the resolver did not assert authentication. That alone does not prove that the name is unsigned; the resolver may have policy or configuration differences.
  • SERVFAIL / Bogus indication: a validating resolver may return this for broken DNSSEC, but SERVFAIL can have other causes too.

Validate locally

Requests DNSSEC records with checking disabled upstream, then rustdns independently verifies signatures, delegation links, and authenticated denial proofs to its built-in IANA root trust anchors. It reports secure or authenticated-insecure only when it can validate that result. Missing records, unsupported algorithms, network failures, and other validation errors are shown as failures—not as proof that a domain is bogus.

DNSSEC dependency queries use the selected DoH endpoint and share a bounded deadline. The app does not send queries to authoritative servers directly.

The Validation Trace pane below the output lists every query made, in order, with its flags, result, and timing. Expand a row to see the full response, including the RRSIG records being checked.

Try it

Back on the app, select Validate locally and try:

  • cloudflare.com A — a signed zone expected to validate.
  • dnssec-failed.org A — a deliberately broken DNSSEC test domain. Depending on the resolver, it may return SERVFAIL or data that local validation rejects.

For comparison, try both with Trust upstream (AD). Resolver behavior, availability, CORS policy, and the domain's current DNS configuration can affect the demonstration.

Protocol flags

  • DO=1 asks for DNSSEC-related records such as RRSIG and denial proofs. Local mode sets it; trust-upstream mode does not need them.
  • CD=1 asks the recursive resolver not to reject data based on its own DNSSEC validation. Local mode uses this so rustdns can inspect and validate the response independently.
  • AD=1 in a response is the resolver's assertion about authenticated data; it is not itself a signature. Trust-upstream mode sets AD=1 in the query to request that assertion without extra DNSSEC records (RFC 6840 §5.7).

Learn more: RFC 4033, RFC 4035, and IANA DNSSEC trust anchors.