DNSSEC Validation: How to Check If Your Domain Is Properly Signed

Why DNSSEC Matters

DNS was not designed with integrity in mind. A resolver asks a nameserver for an A record and trusts whatever comes back. That trust model worked fine in 1987, but it is a disaster today. DNS poisoning, man-in-the-middle hijacking, and cache injection attacks all exploit the same weakness: the resolver has no way to confirm that a response actually came from the authoritative source.

DNSSEC fixes this by adding cryptographic signatures to DNS responses. Every record set in a signed zone gets an RRSIG record — a digital signature produced with the zone's private key. Resolvers use the corresponding DNSKEY record to verify that the RRSIG is valid. If the signature checks out, the response is authentic. If it does not, the resolver treats the answer as bogus and returns SERVFAIL.

That chain of trust goes all the way up. Your zone's DNSKEY is signed by the parent zone's DS record, which is signed by its parent, and so on up to the root zone. A single break in that chain — an expired signature, a missing DS record, a key rollover gone wrong — and your domain stops resolving for DNSSEC-validating resolvers. That is roughly 30% of global DNS traffic today, including Google Public DNS, Cloudflare's 1.1.1.1, and Quad9.

Quick Check: Is Your Domain Signed?

Before digging into validation details, confirm whether DNSSEC is active at all. The simplest way is to query for DNSKEY records:

dig +dnssec example.com DNSKEY

If the zone is signed, you will see DNSKEY records in the answer section and RRSIG records in the authority section. The ad flag (Authenticated Data) in the response header means the resolver you are using validated the response. If you see empty output or a NOERROR with no DNSKEY records, the zone is not signed.

You can also ask for the AD flag explicitly:

dig +dnssec example.com A | grep 'flags:'

If the output shows ad in the flags, validation succeeded. No ad flag means either the zone is unsigned or the chain of trust is broken somewhere between root and your domain. Our DNSSEC analyzer automates this check and walks the full chain for you.

Walking the Chain of Trust

DNSSEC validation is a recursive process. You start at the root and work downward, verifying that each parent zone's DS record matches the child zone's DNSKEY. If any link fails, the whole chain is broken.

Start by checking the root zone's trust anchor. Most validating resolvers ship with the root zone KSK baked in:

dig +dnssec . DNSKEY | grep '257'

This returns the root Key Signing Key (KSK). The flags field value of 257 indicates a KSK (bit 7 set in the flags field means it is a zone key, bit 15 clear means it is not a SEP — technically a quirk of how the root operates, but the key tag and algorithm tell you what you need).

Next, verify your TLD is signed and that the root has a DS record for it:

dig +dnssec com. DS

You should see DS records with valid RRSIGs. The DS record is a hash of the child zone's KSK. If the root's DS hash matches the TLD's DNSKEY, the link is valid.

Now do the same for your domain:

dig +dnssec example.com DS

This queries the parent zone (likely your TLD or registrar's nameserver) for the DS record pointing to your domain. If this returns nothing, your registrar never published the DS record — the most common DNSSEC deployment failure. You may have generated keys and signed your zone, but without the parent-side DS record, validating resolvers have no trust anchor and will treat your domain as insecure.

Inspecting Signature Validity

Every RRSIG record has an inception and expiration time. An expired signature is as bad as no signature at all. Check your zone's signature timestamps:

dig +dnssec example.com SOA +multiline

Look at the RRSIG record in the output. It contains:

example.com. 3600 IN RRSIG SOA 13 2 3600 (
                                20260625120000 20260611120000 12345 example.com.
                                AbCdEfGhIjKlMnOpQrStUvWxYz... )

The two timestamps are expiration and inception, in YYYYMMDDHHMMSS format. The expiration must be in the future and the inception in the past. If signatures expire before your key rollover schedule replaces them, validators will drop your zone. Automate signature refresh — tools like OpenDNSSEC and Knot DNS handle this, but you still need to monitor it.

Also check algorithm compatibility. DNSSEC supports several algorithms, but some (like RSA/SHA-1, algorithm 5/7) are deprecated. Use algorithm 13 (ECDSA P-256) or algorithm 8 (RSA/SHA-256) as a minimum:

dig +dnssec example.com DNSKEY | grep DNSKEY

The third field in the DNSKEY record is the algorithm number. Algorithm 13 is the modern standard. If you are still on algorithm 5, 7, or 8 with short keys, it is time to rotate.

Validating NSEC and NSEC3 Coverage

DNSSEC also provides authenticated denial of existence. When a resolver asks for a name that does not exist, the nameserver returns either NSEC or NSEC3 records that cryptographically prove there are no names between two existing names in the zone. Without this, an attacker could strip signatures and claim a name does not exist when it actually does.

Check your zone's NSEC/NSEC3 responses:

dig +dnssec nonexistent.example.com A

You should see NSEC or NSEC3 records with valid RRSIGs in the authority section, and the response code should be NXDOMAIN. If you see an empty NXDOMAIN with no NSEC/NSEC3 records, your signer is broken.

NSEC3 adds a hashing layer that prevents zone walking (enumerating all names in a zone by following NSEC chains). Most production zones should use NSEC3 with opt-out enabled, unless the zone is public and small enough that enumeration does not matter.

Common DNSSEC Failures

Here are the failure modes we see most often in the field:

Missing DS at parent. The zone is signed, signatures are fresh, but the registrar never published the DS record to the TLD. Without this, the chain of trust ends before it reaches your zone. This is purely a provisioning issue — use our DNS lookup tool to query your domain's DS record at the parent and confirm it exists.

Expired RRSIGs. The signer stopped running, keys are stale, signatures lapsed. Validators see expired signatures and reject the entire zone. Monitor RRSIG expiration dates and set alerts at 25% remaining lifetime.

Key rollover failure. ZSK rollovers are routine, but KSK rollovers are dangerous. If you publish a new KSK in your DNSKEY set but the parent still has the old DS record, resolvers that pick the new key cannot validate. The Double-Signature rollover method (RFC 6781) mitigates this by publishing both old and new keys during a transition window, but you must coordinate with the parent-side DS update carefully.

Algorithm mismatch. A resolver configured to accept only algorithms 8, 13, and 15 will reject a zone signed with algorithm 5, even if the signatures are valid. Upgrading to a modern algorithm requires a full zone re-sign and a coordinated DS update at the parent.

Jitter in signature timestamps. Some signers produce signatures with inception times in the future due to clock skew. If inception is ahead of the validator's clock, the signature appears not-yet-valid and is rejected. Always run NTP on signer hosts.

Automating DNSSEC Monitoring

Manual checks are fine for one domain, but if you operate dozens or hundreds of zones, you need automation. A monitoring script can periodically query each zone for DNSKEY and DS records, validate RRSIG expiration windows, and confirm the AD flag is present through a validating resolver.

#!/bin/bash
# Quick DNSSEC health check for a list of domains
RESOLVER="1.1.1.1"
while read -r domain; do
    result=$(dig +dnssec +short @"$RESOLVER" "$domain" A 2>&1)
    if dig +dnssec @"$RESOLVER" "$domain" SOA | grep -q 'ad;'; then
        echo "OK: $domain (validated)"
    else
        echo "FAIL: $domain (validation failed or unsigned)"
    fi
done < domains.txt

Wire this into your monitoring stack — Nagios, Prometheus, or a simple cron job that emails on failure. DNSSEC breaks silently; nobody notices until users start reporting resolution failures. By the time a helpdesk ticket arrives, the outage may already have been hours old.

Testing Before You Deploy

Before pushing DNSSEC to production, test against multiple validating resolvers. Different implementations handle edge cases differently — what works against Unbound may fail against Google Public DNS. Use our DNSSEC validation tool to check your domain against multiple resolver perspectives simultaneously.

Also test with delv, a dedicated DNSSEC diagnostic tool from BIND:

delv @1.1.1.1 example.com A +vtrace

The +vtrace flag shows every step of the validation walk, including which keys were used, which DS records were found, and where the chain broke if it did. This is far more useful than dig for debugging DNSSEC issues because it shows you the full traversal, not just the final result.

DNSSEC is not optional infrastructure anymore. It is table stakes for any domain that handles login pages, payment forms, or API endpoints. The penalty for getting it wrong is not a warning — it is a hard failure that knocks your domain offline for a third of the internet. Check your chain, automate the checks, and fix problems before users find them.