Dr.Who

dnssec checker

verify the DNSSEC chain-of-trust for a domain — DS record at the parent, DNSKEY at the zone, and the AD flag from cloudflare's resolver. part of the drwho.me domain dossier.

dnssec

info
Open standalone →

checking dnssec…

Overview

DNSSEC (RFC 4033–4035) extends DNS with cryptographic signatures so resolvers can prove that an answer came from the authoritative zone and has not been tampered with in transit. the chain works from the root down: each zone signs its records (RRSIG), publishes its signing keys (DNSKEY), and has the parent zone publish a hash of those keys (DS — delegation signer). a validating resolver walks this chain all the way to the root zone's self-signed key. when validation succeeds the resolver sets the Authenticated Data (AD) flag in its response. this tool queries cloudflare's doh resolver at 1.1.1.1 with the `dnssec_ok` (DO) bit set, checks for a DS record at the parent zone and a DNSKEY at the zone itself, and reads the AD flag from the answer. DNSSEC blocks DNS cache-poisoning attacks (Kaminsky-style), where a forged answer tricks a resolver into serving a rogue ip. US federal civilian agencies are required to deploy DNSSEC under NIST SP 800-81 and OMB M-22-09. note that DNSSEC protects the zone data, not the transport layer — it is complementary to TLS, not a replacement.

How to use

  1. enter a bare domain — public fqdn. no scheme, no port.
  2. run the check — the tool sends three cloudflare doh queries: DS at the parent zone, DNSKEY at the zone, and any RRTYPE with DO=1 to read the AD flag.
  3. read the result — `dnssecEnabled: true` means a DS record exists and DNSKEY is present. `adFlag: true` means cloudflare's resolver validated the chain successfully. both should be true for a fully operational DNSSEC deployment.

Examples

example 1 — cloudflare uses DNSSEC on their own domain — a safe positive control.
input
cloudflare.com
output
dnssecEnabled: true, adFlag: true, DS records present, DNSKEY published
example 2 — most plain informational domains are signed; commercial domains lag more.
input
example.com
output
dnssecEnabled: true, adFlag: true — IANA's example.com is signed by the ICANN root.
example 3 — absence of DS at the parent is the definitive signal that the zone is unsigned.
input
a domain without DNSSEC
output
dnssecEnabled: false, adFlag: false, no DS record at parent

Common mistakes

  • DS at parent, not at the zone itself — the DS record lives in the PARENT zone (e.g. the `.com` zone for `example.com`), not in your own zone. many operators publish DNSKEY but forget to upload the DS hash to their registrar — the chain is broken from the parent's perspective and resolvers treat the zone as unsigned.
  • DNSSEC does not encrypt traffic — DNSSEC proves authenticity of DNS answers; it says nothing about the content of the connection you make to that IP. TLS still provides the confidentiality and transport-layer authentication. a DNSSEC-signed domain with an expired TLS cert is still untrustworthy for HTTPS.
  • key rollovers must be coordinated — rotating a DNSKEY requires a carefully timed sequence: pre-publish the new key, wait for TTL expiry, generate new signatures, then retire the old key. skipping steps breaks the chain for resolvers that have cached intermediate states. some cloud providers automate this; manual DNSSEC management is error-prone.
  • AD flag reflects the resolver's view — cloudflare 1.1.1.1 validates DNSSEC by default. the AD flag in this tool's result shows whether cloudflare validated the chain — not whether YOUR resolver does. stub resolvers (most home routers) don't validate at all; they trust whatever the upstream returns.

FAQ

what is the AD flag?

the authenticated data flag in a DNS response. a resolver sets it to signal that the returned data has been validated via DNSSEC according to the resolver's trust anchors. cloudflare validates by default so AD=true means the chain is intact from their perspective.

can DNSSEC be broken by a misconfigured registrar?

yes, and this is the most common real-world failure. the registrar must publish the correct DS record at the parent zone. if you roll your DNSKEY without updating the DS at the registrar, every validating resolver will start returning SERVFAIL for your domain — effectively taking it offline for anyone on a strict resolver.

why are DS records at the parent and DNSKEY at the zone?

DS (delegation signer) is a hash of the zone's key-signing key (KSK). the parent zone signs the DS, linking the two zones cryptographically. the zone's own DNSKEY set is then trusted because the parent DS vouches for it. the parent cannot self-vouch — that would allow zone operators to forge signatures for any name.

does enabling DNSSEC affect my site's uptime risk?

yes. unsigned domains fail gracefully (resolver returns the unsigned answer). broken DNSSEC causes SERVFAIL — full resolution failure for validating resolvers. so DNSSEC increases the blast radius of a misconfigured key rollover from 'possible cache poisoning' to 'site down for 20-30% of users'. test key rollovers in a staging zone first.

is DNSSEC required for DMARC or email auth?

no. SPF, DKIM, and DMARC work over unsigned DNS. DNSSEC is a separate layer that protects all DNS records including those used for email auth — but email auth does not depend on it. it's good defence-in-depth, not a prerequisite.

can ai agents call this?

yes — dossier_dnssec on the mcp endpoint at drwho.me/mcp/mcp.

Related tools

  • dns records lookup — resolve A, AAAA, NS, SOA, CAA, and TXT records for a domain in one go.
  • mx lookup — list the mail exchangers (MX records) a domain advertises, sorted by priority.
  • tls certificate checker — inspect a domain's TLS certificate: subject, issuer, validity, SANs, fingerprint.

References

  1. RFC 4033 — DNSSEC Introduction
  2. RFC 4034 — Resource Records for DNS Security Extensions
  3. ICANN — DNSSEC: What Is It and Why Is It Important?
ad slot · tool-dnssec-checker