HTTPfy

DNSSEC Inspector

Walk the DNSSEC chain of trust from the root down.

DNSSEC Inspector Ready

About DNSSEC Inspector

DNSSEC Inspector

DNSSEC Inspector checks whether a domain publishes the records DNSSEC needs at each level of its chain of trust: the root zone, the TLD (such as .com) and the domain itself. Enter a domain such as example.com and the tool reports what it finds at each level, then lists the domain's A records.

What DNSSEC Does

DNSSEC adds digital signatures to DNS answers. A validating resolver checks those signatures, so an attacker can't feed it a forged record. DNSSEC provides:

  1. Proof that an answer came from the zone owner
  2. Proof that nobody changed the answer in transit
  3. Signed proof that a name or record type doesn't exist

DNSSEC doesn't encrypt anything. Anyone on the path can still see which names you look up. DNS over HTTPS or DNS over TLS handle privacy.

The Records Involved

  • DNSKEY: the zone's public keys. A zone usually has a key-signing key (KSK, flags 257) and a zone-signing key (ZSK, flags 256).
  • RRSIG: a signature over a set of records.
  • DS: a hash of the child zone's KSK, stored in the parent zone. It links each level to the next.
  • NSEC/NSEC3: signed records that prove a name doesn't exist.

What the Tool Checks

  1. Whether each zone (root, TLD, domain) returns DNSKEY records, with key tags and algorithms
  2. Whether RRSIG records cover each zone's DNSKEY set
  3. Whether the parent zone holds a DS record for the TLD and for the domain, and whether that DS set is signed

Each zone gets a GREEN, YELLOW or RED status, and the summary at the top turns RED if any zone isn't GREEN. The tool sends its queries through Google Public DNS (8.8.8.8). It reports which records exist but doesn't verify the signatures cryptographically or check their expiry dates. For a full validation, run delv example.com or use DNSViz.

Enter the registered domain (example.com), not a subdomain. The tool treats the label above your input as the TLD, so www.example.com gives misleading results.

Common Problems

  1. No DS record at the parent: the zone is signed but the registrar never published the DS, so resolvers treat the domain as unsigned.
  2. DS doesn't match any DNSKEY: usually left over after a key rollover or a DNS provider change. Validating resolvers return SERVFAIL and the domain goes offline for their users.
  3. Expired signatures: the signer stopped re-signing the zone. Validating resolvers reject the answers.
  4. Moving DNS providers while signed: remove the DS at the registrar first, wait for the old DS TTL to pass, then switch. Or follow the new provider's signed-migration steps.

Deployment Tips

  1. Use algorithm 13 (ECDSAP256SHA256). It's widely supported and gives small signatures. Algorithm 8 (RSASHA256) is also fine.
  2. Let your DNS host sign the zone and rotate the ZSK automatically.
  3. If your registrar and DNS host support CDS/CDNSKEY records, use them so DS updates happen without manual steps.
  4. Monitor signature expiry and DS/DNSKEY matches after every change.

Further Reading