DNSSEC Checker
Check whether a domain has DNSSEC (DS/DNSKEY) enabled.
DNSSEC Checker verifies whether a domain has DNSSEC (DNS Security Extensions) signing enabled. It queries the DS record registered in the parent zone and the zone's own DNSKEY record in parallel, then tells you at a glance whether the domain is signed.
A DNSSEC-signed domain lets resolvers cryptographically verify that responses haven't been tampered with, protecting DNS answers from attacks like cache poisoning. Just enter a domain — no protocol or path needed. Queries go to a trusted public resolver over DNS over HTTPS. Check the domain's other records with DNS Record Lookup and its delegated nameservers with NS Check.
What DNSSEC is
Plain DNS responses aren't signed, so a tampered answer is hard for clients to detect. DNSSEC attaches a digital signature to each zone's records and validates that signature through a chain of trust up to the parent zone, guaranteeing the integrity and origin of responses.
DS records and DNSKEY records
- DNSKEY: the public key a zone uses to sign its own records. It lives inside the zone.
- DS (Delegation Signer): a hash of the DNSKEY, registered in the parent zone (e.g. .com). It links a parent's trust to the child zone's key.
- If either record exists, this tool reports DNSSEC as enabled. Full validation, however, requires both DS and DNSKEY to be correctly linked.
Why it matters
The DS record must be registered in the parent zone for the chain of trust to complete. If a DNSKEY exists but no DS, validation may not actually happen. When you move a domain or roll over keys, a missing DS entry can cause DNSSEC validation failures that block access to the site — so periodic checks are worthwhile.
DS digest and DNSKEY algorithm reference
A DS record is four fields: key-tag algorithm digest-type digest. When you compare the DS at the registrar with the DNSKEY published in the zone, the numbers below are what you're matching. Algorithm 13 (ECDSA P-256) and digest type 2 (SHA-256) are today's recommended defaults; RSA/SHA-1 (algorithm 5, digest type 1) is deprecated and rejected by many resolvers.
| Field | Value | Meaning |
|---|---|---|
Algorithm 8 | RSA/SHA-256 | Still the most common; large keys mean larger responses |
Algorithm 13 | ECDSA P-256/SHA-256 | Recommended; short keys help response size and amplification |
Algorithm 5 | RSA/SHA-1 | Deprecated; rejected by some resolvers |
Digest 1 | SHA-1 | DS hash type; not recommended for new records |
Digest 2 | SHA-256 | Current standard; register DS with this |
DNSKEY flag 257 | KSK (Key Signing Key) | The key a DS points to; vouched for by the parent zone |
DNSKEY flag 256 | ZSK (Zone Signing Key) | Signs actual records; not referenced by a DS |
A worked example
Say a domain's DS record reads 12345 13 2 9F1A...C3 and the zone publishes a DNSKEY with flag 257 and algorithm 13 (a KSK). Here the algorithm matches (13 on both sides) and the DS key tag (12345) equals that KSK's key tag, so the chain of trust links up — healthy. Now suppose you roll over keys, publish a new KSK in the zone (key tag 60001), but the parent DS still points at the old 12345. This tool will still report “DNSSEC enabled,” yet real validation breaks with SERVFAIL. Always check that the key tag and algorithm number agree on both sides.
Common pitfall
- This tool's “enabled” means only that a DS or DNSKEY exists. It does not prove the DS points at the right key (matching key tag and algorithm), so don't read “present” as “validates.”
- The classic outage is forgetting to register the new DS during a key rollover or DNS provider migration: the DNSKEY is the new key while the parent DS still references the old one. The site then fails (
SERVFAIL) only behind validating resolvers, which makes the cause hard to spot.