DNSSEC check

The gap DNSSEC closes

When your computer asks “what is the address of example.com?”, the answer comes back as a small unprotected packet. The original DNS gives the receiver no way to check who wrote it. Someone sitting between you and the name server, or someone who slips a forged answer into a resolver’s memory, can send visitors and mail to a machine of their choosing.

DNSSEC adds signatures. The owner of a zone signs every set of records with a private key and publishes the matching public key in the zone as a DNSKEY record. A resolver that receives an answer also gets its signature (RRSIG) and can verify that the records are exactly what the owner published. DNSSEC doesn’t encrypt anything and doesn’t hide which names you look up. All it does is prove that an answer is genuine.

A chain of fingerprints

A public key sitting in the same place as the data doesn’t prove much, since a forger could replace both. So each zone asks the zone above to vouch for it. The parent publishes a DS record, a short fingerprint (digest) of the child’s key, and signs that record with its own key. The parent’s key is vouched for by its own parent in the same way, all the way up to the root zone. The root key is the one thing a resolver has to know in advance, and it ships with the resolver software.

For example.com the path goes like this: root key, DS for com in the root, keys of com, DS for example.com in com, keys of example.com, signed records. One missing or wrong link and the proof fails.

The DS record is the part that lives outside your DNS host. It’s handed to the registry through your registrar, and most failures come from that split.

What this check does

For the root, the top-level zone and each zone down to your domain, our server reads the DS records at the parent and the DNSKEY records of the zone. It reads them through public resolvers with validation switched off (the “checking disabled” flag), so it can still inspect a broken zone. For every key it computes the key tag, and for every DS it recomputes the digest from the key with the same hash function (RFC 4034) and compares the two byte for byte.

Then it asks three validating public resolvers (Cloudflare, Google and Quad9) for the domain’s SOA record, this time with validation on. A resolver that validated the answer sets the AD flag (“authenticated data”). One that found a fault answers SERVFAIL. Our server matches fingerprints itself, but it doesn’t verify the signatures. That verdict belongs to the resolvers.

The check also flags algorithms that are retired or weak (RSA/MD5, DSA, RSA/SHA-1, SHA-1 digests in a DS), a DS left over from an old key, signatures within three days of their end date, and whether the zone uses NSEC or NSEC3 to prove that a name doesn’t exist.

Fixing a broken chain

A broken chain is worse than no DNSSEC at all, because validating resolvers refuse to answer. It usually goes like this: the domain moved to a new DNS host, the old DS record stayed behind at the registrar, and it now points to a key that no longer exists.

1. To get back online fast, delete the DS record at the registrar. The domain becomes unsigned and works for everyone once caches expire, typically within a day.
2. To keep DNSSEC, open the DNSSEC page of your current DNS host, copy the DS record it shows (key tag, algorithm, digest type, digest) and enter it at the registrar in place of the old one.
3. Before the next move, remove the DS record first, wait a day, change name servers, then sign and publish the new DS.

For “half configured”, either finish the job by publishing the DS record or switch signing off at the DNS host.