Five servers, and what each was built to be good at

What DNSSEC does, and what it does not

Signatures prove a record came from the zone; they say nothing about whether the zone is right, and nothing at all about privacy.

A hardware security module in a rack with a key switch on the front panel — Which server is installed matters less than the decision made before it was installed: answer for a zone, or resolve on somebody else’s behalf.Photograph

What signing actually guarantees

DNSSEC adds cryptographic signatures to DNS records. When a resolver retrieves an answer, it can verify that the record was signed by the key the zone owner registered with the parent — and that the record has not changed in transit. That is a meaningful guarantee against one specific threat: on-path modification, where someone between the authoritative server and the resolver alters the answer before it arrives.

The mechanism works through a chain of trust anchored at the root. The root zone is signed, and its key-signing ceremony ↗ is a documented public event run by IANA. Each parent zone signs a hash of the child's public key — this is the DS record — so a resolver that trusts the root can follow the chain through TLD to zone without trusting any individual operator along the path. NLnet Labs' Unbound and ISC's BIND both perform this validation by default in their current releases; RFC 4033 ↗ is the specification that defines the security model.

What the signature does not cover is whether the signed content is correct. A zone owner can sign a record that points to the wrong address, a decommissioned server, or a hostile host. The signature will verify cleanly. DNSSEC authenticates the source of the answer; it does not audit the intent or accuracy of the zone data itself.

An adult engineer at an open rack door in an exchange-point facility, hand on a labelled cable — Cable labels are the only place a delegation is written down in the physical world. Where they disagree with the zone, the zone wins and nobody finds out for months.Photograph

What it does not do

DNSSEC does not encrypt. A query and its signed response travel in plaintext — anyone on the path can read the name being resolved, and the IP address returned. For operators who care about query privacy, that problem is addressed by DNS over TLS (port 853) or DNS over HTTPS, both of which are entirely separate mechanisms that work whether or not DNSSEC is deployed. DNSSEC signatures can accompany a response sent over an encrypted transport, but they serve different purposes and neither requires the other.

DNSSEC also does not protect against a compromise at the source. If the zone's private key is stolen, or if the registrar account is hijacked, an attacker can sign fraudulent records that validate perfectly. The security property collapses at the keying layer, not at the protocol layer. Key rollovers — regular rotation of both the Key Signing Key and the Zone Signing Key — exist precisely because private key material has a shelf life.

There is also the matter of what DNSSEC signals to resolvers when something is wrong. A validating resolver that receives a response it cannot verify will return SERVFAIL, not the record. From the client's perspective this looks identical to a server failure. Operators who deploy DNSSEC but fail to renew signatures on time — a common misconfiguration, because signature expiry is operationally distinct from zone TTL — cause their zone to disappear entirely from the perspective of validating resolvers. CZ.NIC's DNSSEC monitoring tools exist largely because this failure mode is quiet and complete.

Negative answers are also signed: NSEC and NSEC3 records prove that a name does not exist in the zone. NSEC3 was designed specifically to reduce zone walking — the ability to enumerate every name in a zone by following NSEC chains — but it does not eliminate that possibility; it makes it computationally more expensive.

Deploying it honestly

The operational reality is that DNSSEC raises the cost of certain attacks — chiefly cache poisoning — and introduces new failure modes of its own, primarily around key management and signature expiry. Neither the benefit nor the risk should be overstated. D. J. Bernstein's long-standing scepticism of the protocol's complexity is a matter of public record, and the operational community has spent years refining tooling to manage the parts that break most often.

For an operator: sign your zone, automate signature renewal, monitor validation from outside your network, and understand that the chain of trust you're joining only extends to the boundary of what you control.

The operational reality is that DNSSEC raises the cost of certain attacks — chiefly cache poisoning — and introduces new failure modes of its own, primarily around key management and signature expiry.

A patch panel with numbered ports and neatly combed fibre looms — Numbered ports are a name’s last hop. Everything above them is a chain of referrals that exists only as records in other people’s zones.Photograph

DNSSEC signatures can accompany a response sent over an encrypted transport, but they serve different purposes and neither requires the other.