DNSSEC explained

The problem

When a resolver asks for the address of a name, it accepts the first plausible answer that arrives. Classic DNS has no signature and no encryption, so an attacker who can inject a forged reply, or who controls a network the query passes through, can direct users of that resolver to a server of their choosing. This is called cache poisoning, because the false answer is stored and served to everyone who asks until it expires.

DNSSEC, the DNS Security Extensions, addresses this by having the zone owner sign the records. A resolver that validates can check the signature against a published key and reject anything that does not verify. The data itself is unchanged and still public; what is added is proof of where it came from and that it was not altered.

The records involved

DNSSEC adds four record types. A DNSKEY record holds a public key of the zone. An RRSIG record is a signature over a set of records of one type at one name. A DS record, published in the parent zone, contains a hash of the child zone's key and is what links the two. NSEC or NSEC3 records make it possible to prove that a name or record type does not exist, so that a forged answer of nothing can be detected as well.

Most zones use two keys. The zone signing key signs the ordinary records. The key signing key signs only the set of DNSKEY records, and it is the key signing key that the DS record in the parent refers to. Splitting them lets the zone signing key be replaced frequently without involving the parent.

dig example.com DNSKEY +short
257 3 13 mdsswUyr3DPW132mOi8V9xESWE8jTo0d...   ; key signing key
256 3 13 oJMRESz5E4gYzS/q6XDrvU1qMPYIjCWz...   ; zone signing key

dig example.com A +dnssec +short
203.0.113.10
A 13 2 300 20261124000000 20261110000000 34505 example.com. Kx9c...

The chain of trust

A signature is only useful if the key that made it can be trusted. DNSSEC solves this with a chain that follows the DNS hierarchy. The root zone's key is built into validating resolvers. The root signs a DS record for each top-level domain, which vouches for that domain's key. The top-level domain in turn signs a DS record for your domain, which vouches for your key, and your key signs your records.

Validation walks this chain from the root down. If every link verifies, the answer is marked secure. If a zone has no DS record in its parent, the chain ends there legitimately and the zone is treated as unsigned: answers are accepted without validation, exactly as before DNSSEC existed. The dangerous state is in between, when a DS record exists and the signatures do not match it. Then a validating resolver must refuse the answer.

dig example.com DS +short
34505 13 2 5C6E0A1E9B7D4F...   ; key tag, algorithm, digest type, digest

What you get from it

The direct benefit is that users of validating resolvers cannot be sent to a forged address for your domain by tampering with DNS in transit. Several large public resolvers and many internet providers validate.

DNSSEC also strengthens other records that live in DNS. It protects the CAA record that tells certificate authorities who may issue for you, and authorities that validate DNSSEC will refuse to issue if validation fails. It protects MX, SPF and DMARC records from being forged in transit. And it is the foundation of DANE, which lets a domain publish in DNS which certificate its mail servers use.

What it does not do

DNSSEC authenticates; it does not encrypt. Queries and answers remain visible to anyone on the path. Privacy for DNS queries comes from separate technologies that encrypt the connection between a device and its resolver.

It does not protect against changes made by someone with access to your DNS provider or registrar account: records edited there are signed like any others. It does not protect users whose resolver does not validate. And it does nothing about the content served at the address once the user gets there, which is what TLS certificates are for.

Enabling DNSSEC

Enabling it involves two parties: the DNS provider, which signs the zone, and the registrar, which passes the DS record to the registry. When the same company is both, it is often a single switch. When they differ, the DS record has to be copied from one to the other by hand.

1. Confirm that both your DNS provider and your registrar support DNSSEC for your top-level domain.
2. Turn on signing at the DNS provider. The zone now serves DNSKEY and RRSIG records, and nothing else changes yet.
3. Check that the zone is signed correctly by querying for the DNSKEY records and a signed answer.
4. Copy the DS record details the provider shows: key tag, algorithm, digest type and digest.
5. Enter them at the registrar. Some registrars ask for the DNSKEY instead and compute the DS record themselves.
6. Wait for the DS record to appear in the parent zone, then test with a validating resolver and a DNSSEC analysis tool.

dig example.com A @1.1.1.1 +dnssec
;; flags: qr rd ra ad;        <- the ad flag means the answer was validated

Algorithms

The algorithm number in the DNSKEY and DS records says how the signatures are made. Algorithm 13, ECDSA with the P-256 curve, is the common modern choice: its keys and signatures are small, which keeps responses short. Algorithm 8, RSA with SHA-256, is older and still widely used. Algorithms based on SHA-1 are deprecated and should not be chosen for a new deployment. For the DS record, digest type 2, which is SHA-256, is the standard choice. In practice the DNS provider selects these, and the only decision is whether to accept its defaults.

How DNSSEC takes a domain offline

Almost every DNSSEC outage has the same shape: the DS record in the parent refers to a key that the zone no longer uses. Validating resolvers then see signatures they cannot link to the chain and return SERVFAIL for every name in the domain. Website, mail and every subdomain fail together, but only for users behind validating resolvers, which makes the incident confusing: it works for some people and not for others.

1. Changing DNS providers while the old DS record is still at the registrar. The new provider signs with different keys, or does not sign at all.
2. Changing nameservers at the registrar to a provider where DNSSEC was never enabled, leaving the DS record behind.
3. Switching signing off at the DNS provider without first removing the DS record.
4. A key rollover in which the DS record was not updated to the new key signing key.
5. Signatures that expired because the signing system stopped running.

Changing DNS providers safely

The simplest reliable method is to go unsigned for the duration of the move. It gives up validation for a day or two and removes the possibility of a mismatch.

1. Remove the DS record at the registrar. Do not touch anything else yet.
2. Wait at least as long as the DS record's TTL, typically a day, so that no resolver still holds the old DS record.
3. Confirm from a validating resolver that the domain still resolves and is now treated as unsigned.
4. Change the nameservers to the new provider.
5. After the move has settled, enable signing at the new provider.
6. Add the new DS record at the registrar.

dig example.com A @1.1.1.1         ; SERVFAIL
dig example.com A @1.1.1.1 +cd     ; answers, so validation is failing
dig example.com DS +short          ; the DS the parent publishes
dig example.com DNSKEY +short      ; the keys the zone actually has

Recovering from an outage

If the domain is failing validation and the cause is not immediately fixable, remove the DS record at the registrar. Once resolvers' cached copies of it expire, the domain is treated as unsigned and resolves again. This is the fastest route back to service. It cannot be hurried, because the old DS record stays in caches for its TTL, which is why outages of this kind commonly last hours even after the right fix is applied.

Re-enable DNSSEC afterwards as a planned change, following the normal order.

Should you enable it

For most domains the answer is yes, with a condition. Where the DNS provider and registrar are the same company, or the provider automates the DS record, DNSSEC runs unattended and the risk is small. Where the DS record is maintained by hand across two companies, it is still worth having, provided the dependency is written down where the next person who changes providers will see it. An undocumented DS record is the usual cause of a migration turning into an outage.

Whichever applies, monitor it. The CloudSpex DNSSEC Checker reads the DS record and the zone's keys and reports whether the chain validates, so that a mismatch is noticed before or immediately after a change rather than through support tickets.