Test DNS › DNS guides

DNSSEC: principles of signing and validation

The original DNS verifies nothing: a response arrives, and it is believed. DNSSEC adds signatures so that the resolver can distinguish an authentic response from a forged one, at the cost of a chain of trust that has to be built from the root down to the zone.

Bunch of metal keys lying on a computer keyboard — DNSSEC rests on published keys and signatures: security comes from verification, not from keeping names secret.

The problem DNSSEC solves

A conventional DNS response comes with no proof of origin. An intermediary able to inject a packet can supply a false address, and the resolver will cache it as a legitimate response. DNSSEC provides origin authentication and data integrity: the response really does come from the zone it claims, and it has not been modified on the way.

DNSSEC does not encrypt anything. The names queried and the responses remain readable by anyone observing the network, which explains why it coexists with encrypted transports such as DNS over TLS or DNS over HTTPS, which deal with confidentiality on the wire. Confusing the two objectives leads to false expectations, particularly about protecting the names being looked up.

The mechanism also covers absence: when a name does not exist, the zone signs a proof of non-existence. Without that, an attacker could simply answer that the name does not exist, and the resolver would have no means of contradicting it.

Keys, signatures and the chain of trust

A signed zone publishes its public keys in DNSKEY records, and an RRSIG for each record set. A resolver that knows the public key can verify that the set has not been altered. The formats and the processing rules are described in RFC 4034 and 4035, with RFC 4033 setting out the overall architecture.

It remains to be seen whether the public key itself is authentic. The answer lies in the DS record, published by the parent zone: it holds the digest of a key from the child zone, signed by the parent. The resolver therefore validates step by step, from the root key that it knows through configuration down to the zone being queried. This succession of signed delegations is the chain of trust, and it breaks as soon as one link is missing.

Proving absence with NSEC and NSEC3

Signing an affirmative response is simple; proving that a name does not exist means signing something else. The first approach, NSEC, chains the existing names in canonical order: the response indicates between which existing names the name being sought would fall, and that assertion is signed. Its drawback is that it reveals the zone's inventory to anyone who knows how to explore it.

NSEC3, defined in RFC 5155, replaces the names with their cryptographic digest, which limits that enumeration. The two mechanisms coexist, and the choice has operational consequences: signing CPU cost, response size, and the behaviour of older resolvers. A change of mechanism on a production zone is prepared, not improvised.

Validation happens at the resolver

A client generally does not validate: it trusts its resolver. It is the recursive resolver that walks the chain, checks the signatures and decides. When everything is valid, it can mark the response as authenticated; when validation fails, it must return a resolution error rather than a doubtful response.

This rule explains the most baffling symptom of DNSSEC: a domain that works for some users and not for others. Resolvers that validate fail, those that do not validate answer normally. Before blaming the network, then, you have to know whether the resolver opposite performs validation, and read the error code returned rather than the name of the site.

Running a signed zone

A signed zone has a lifetime: signatures expire, and the resolver then refuses the responses. Renewal must be automatic, with an alert on the age of the oldest signature. A modern name server can manage a signing policy that takes over this work, provided the machine's clock is right: a clock drift is enough to invalidate every signature.

Keys are renewed too, and the transition procedure has to be written before it is needed. The zone signing key, renewed often, needs only a republication; the delegation key, whose digest appears at the parent, requires coordination with the registrar or with the operator of the parent zone. A rotation missed at that level makes the domain invalid for every validating resolver.

The mistakes that break resolution

Three mistakes keep coming back. Signing a zone without publishing the DS record at the parent: the signatures exist but no chain links them to the root, the zone stays unvalidated, which is harmless but pointless. Publishing a DS for an unsigned zone: the domain becomes invalid for every validating resolver. Changing key without updating the DS: same result, often after a few days of normal operation.

The fourth mistake is more discreet: keeping algorithms or key sizes that the recommendations regard as obsolete. The domain carries on working, then suddenly stops when the resolvers withdraw support. RFC 8624 keeps those recommendations up to date, and deserves a reread at every architecture review rather than in an emergency.

References

To check a domain name live — root, TLD, name servers — use the DNS test tool. Demarcq.net runs DNS servers: managed DNS operations.

← Setting up a secondary DNS server: value, limits and good practice TTL and the propagation of zone changes →