DNS was born in an era when the network was trusted. A normal DNS response contains no proof of origin: the resolver accepts whatever it receives, as long as it arrives in the expected way. DNSSEC adds a verifiable digital signature to responses, so that a resolver can tell whether someone has forged or altered them along the way.
The problem it solves
Without DNSSEC, an attacker able to insert false answers into a resolver's cache (so-called cache poisoning) can send users to servers other than the real ones. HTTPS greatly limits the damage, because the browser flags an invalid certificate, but DNS is not only for the web: email, software updates, telephony and many internal services rely on correct DNS answers.
DNSSEC guarantees two things:
- authenticity: the answer really comes from the zone it claims to represent;
- integrity: nobody modified it in transit.
It is worth being clear about what it does not do: it does not encrypt queries and does not hide which sites you visit. Confidentiality is handled by different protocols, such as DNS over HTTPS or DNS over TLS. The two approaches complement each other.
The chain of trust, in plain words
Each signed zone publishes its public keys in records called DNSKEY and attaches a signature to each set of records, held in RRSIG records. A resolver can check the signature with the zone's key.
But how does the resolver trust that key? Through the parent zone. The parent domain publishes a DS (Delegation Signer) record containing a fingerprint of the child domain's key. In turn, the DS record is signed with the parent's key.
This forms a chain:
- the DNS root is signed, and resolvers know its key in advance;
- the root signs the DS record of the TLD, for example .com;
- the TLD signs the DS record of example.com;
- example.com signs its own records, such as the address of www.
If a link is missing or does not match, a DNSSEC-validating resolver rejects the answer and returns an error (SERVFAIL), rather than handing out potentially false data.
Two kinds of key
Many setups use two separate keys:
| Key | Function | How often it changes |
|---|---|---|
| KSK (Key Signing Key) | Signs only the key set; its fingerprint goes into the DS at the parent | Rarely |
| ZSK (Zone Signing Key) | Signs the zone's records | More often |
The split allows the ZSK to be renewed without touching the DS record at the registrar. Some providers use a single key instead: for whoever manages the domain the difference is often invisible, because everything is automated.
How to enable it in practice
For most domains the procedure is simple:
- enable signing in the panel of the DNS provider hosting the zone; the provider generates the keys and signs the records automatically;
- copy the DS record data the provider shows you (key tag, algorithm, digest type, digest);
- enter them at the registrar, in the domain's DNSSEC section. If registrar and DNS provider are the same, a single click is often enough;
- verify with a DNSSEC analysis tool or with
dig +dnssec example.com: RRSIG records must appear in the answers, and a validating resolver should flag the answer as authenticated.
Some registries and providers also support automatic DS publication through CDS records, reducing manual work.
The critical moment: changing DNS provider
Most DNSSEC-related outages come from a botched migration. If you move the zone to a new provider while leaving the old DS record at the registrar, validating resolvers will find keys that do not match and treat the domain as invalid. Website and email become unreachable for a large share of users.
The safest sequence, if the new provider does not support a migration with shared keys, is:
- remove the DS record at the registrar;
- wait for the DS TTL in the TLD zone to expire;
- move the NS servers to the new provider;
- enable signing at the new provider and publish the new DS.
This way the domain is temporarily unsigned, but always reachable.
Is it worth enabling?
For a domain that hosts important services, yes, provided the provider handles signature renewal automatically. Signatures have an expiry date: if they are not regenerated, the domain stops resolving. That is why it pays to rely on providers that automate the whole cycle and to keep track of where DNSSEC is active.
In short
- DNSSEC signs DNS answers and guarantees their authenticity and integrity, not their confidentiality.
- Trust flows from the root to TLDs to domains through DS and DNSKEY records.
- You enable it by signing the zone at the provider and publishing the DS at the registrar.
- The main risk is changing provider while leaving an outdated DS in place.
- Rely on providers that renew signatures automatically.
