DNS GUIDE

DNSSEC explained

DNSSEC lets resolvers detect forged DNS answers. It also introduces new ways to break a domain. This guide covers the mechanics and the safe order of operations.

The problem DNSSEC addresses

Classic DNS has no way to prove that an answer came from the zone owner. A resolver accepts whatever arrives in a reply that matches its question, so an attacker who can inject or alter replies on the path, or poison a cache, can send users to the wrong address. DNSSEC (RFC 4033 to 4035) adds public-key signatures to DNS data so that a resolver which validates can reject a forged or altered answer.

It is worth being exact about the scope. DNSSEC authenticates DNS data and proves that a name does not exist when it does not. It does not encrypt queries, it does not hide which names you look up, and it does not make the destination server trustworthy. It is also optional, and a large share of working domains are unsigned.

The records involved

DNSKEY: the zone's public keys, published in the zone. Zones commonly use a key-signing key (KSK) that signs the key set and a zone-signing key (ZSK) that signs the data.
RRSIG: a signature over one record set, with an inception time, an expiry time, the key tag and the algorithm of the key that made it.
DS: published in the parent zone. It holds the key tag, algorithm, digest type and a digest of a child DNSKEY. This is the link that carries trust from parent to child.
NSEC or NSEC3: signed records that prove a name or a record type does not exist, so that negative answers can be validated too.

How validation works

A validating resolver begins with a trusted key for the root. The root zone's data includes DS records for top-level domains, each of which matches a key in the TLD, whose data includes DS records for domains such as example.com, and so on. At each step the resolver checks that the DS matches a DNSKEY, that the DNSKEY set is signed by that key, and that the answer's RRSIG verifies with a key in the set and is inside its validity period.

If everything verifies, the resolver returns the answer with the AD flag set. If the zone has no DS at the parent, the resolver treats it as unsigned and answers normally. If a DS exists but the chain fails, the answer is bogus, and the resolver returns SERVFAIL. This is the important asymmetry: an unsigned zone works, a correctly signed zone works, and a half-configured one stops working for everyone behind a validating resolver.

What goes wrong in practice

Stale DS after a provider change: the DS at the registrar refers to keys that the new provider does not serve.
Expired signatures: the signing process stopped or the signer lost its key material, and the validity period ran out.
Key rollover mistakes: the DS was updated before the new key was published and cached, or the old key was removed while signatures still depended on it.
Mismatched parameters: the algorithm or digest type in the registrar form does not match the key.
Inconsistent secondaries: one name server serves the signed zone and another serves an unsigned or old copy.
Resolvers disagree: some resolvers validate and some do not, so a problem is visible only to part of your audience.

Enabling DNSSEC safely

Confirm that your DNS provider can sign the zone and that your registrar accepts DS records for your TLD.
Enable signing at the DNS provider and wait until DNSKEY and RRSIG records are served by all authoritative servers.
Copy the DS values (key tag, algorithm, digest type, digest) exactly into the registrar.
Run the DNSSEC Checker: the DS should match a DNSKEY, signatures should be current, and validating resolvers should return AD.
Monitor signature expiry, since an automated signer failing silently is the most common long-term failure.

Disabling DNSSEC or changing providers

The order is the reverse of enabling. Remove the DS record at the registrar first. Wait until the DS TTL set at the parent has expired everywhere, which can be a day or longer, so that no resolver still expects signatures. Only then stop signing and remove the keys. Reversing the order leaves a window in which validating resolvers hold a DS for keys that no longer exist, and the domain fails for them.

For a move between providers, either turn DNSSEC off beforehand as described, or use a provider arrangement in which both sets of keys are published. Do not change name servers while a DS at the registrar points to the old provider's keys.

Key rollover in brief

Keys are replaced periodically or after a suspected compromise. Zone-signing keys can be rolled inside the zone without touching the parent. Rolling a key-signing key changes the DS, so the new key is published first alongside the old one, the new DS is added at the parent, the old DS is removed only after caches have had time to expire, and the old key is withdrawn last. Most managed DNS providers automate this; verify after each rollover with a checker.

Diagnosing a failure

A domain that works on some resolvers and returns SERVFAIL on others is a classic DNSSEC symptom, because validating and non-validating resolvers behave differently. Compare them with the DNS Resolver Comparison and examine the chain with the DNSSEC Checker. Read troubleshooting NXDOMAIN, SERVFAIL and timeouts for the other causes of SERVFAIL, since a lame or unreachable server produces the same error code.

As an emergency step when a domain is bogus, removing the DS at the registrar makes the zone unsigned and restores resolution once the parent's TTL expires, at the cost of losing DNSSEC protection until you fix and re-add it.