DNSSEC Explained: Signing DNS to Stop Spoofing

DNS is the address book of the internet, and for most of its life it ran on trust. When your resolver asked for the address of a domain and got an answer, it believed the answer. Nothing in the original protocol proved the reply came from the real owner of the name. An attacker who could inject a forged response, or poison a resolver's cache, could send users to a server of their choosing while the address bar looked normal. DNSSEC exists to close that gap.

DNSSEC, the DNS Security Extensions, adds cryptographic signatures to DNS records. A resolver can check that a signature was produced by the legitimate owner of the zone and that the record has not been altered in transit. It turns DNS from believe-what-you-are-told into verify-then-believe.

The problem it solves

Plain DNS answers are trivially forgeable to an attacker in the right position. Two classic attacks:

• Cache poisoning. An attacker races the real reply and gets a forged answer accepted into a resolver's cache. Every user of that resolver is then sent to the attacker's address until the entry expires.
• On-path spoofing. An attacker who sees the query injects a fake response before the real one arrives.

The result is the same. Users type the right name and land on the wrong server. For the wider family of these attacks, see DNS Spoofing Explained.

DNSSEC does not stop the forged packet from arriving. It makes the forged packet fail verification, so a validating resolver discards it.

The stakes are high because DNS sits underneath almost everything else. Redirect a domain and you can steer users to a fake login page, intercept email by pointing mail records at your own server, or defeat certificate issuance by forging the domain-control check a certificate authority relies on. A single successful DNS forgery can quietly undo protections that look solid at every other layer. That leverage is why an integrity guarantee at the DNS layer is worth the operational cost it carries.

How signing works

Every DNSSEC-enabled zone has a key pair. Records in the zone are signed with the private key, producing a signature stored in a new record type. When a resolver fetches a record, it also fetches the signature and the zone's public key, then checks that the signature is valid for that record.

DNSSEC introduces a handful of new record types. The names matter less than the roles.

The NSEC family solves a subtle problem. Signing records that exist is straightforward. Proving that a name does not exist, without letting an attacker forge a "does not exist" answer, needs its own signed mechanism. That is what NSEC and NSEC3 provide.

Most zones use two keys rather than one. A key-signing key (KSK) signs only the key records, and a zone-signing key (ZSK) signs the actual data. This split lets operators rotate the working key often while the anchored key stays stable. The reason is practical. The KSK is the key the parent zone commits to, so changing it means updating the DS record in the parent, a slower coordinated step. The ZSK signs the bulk of the records and can be rotated freely without ever touching the parent. Separating the two means routine key rotation does not drag the parent into every change.

The chain of trust

A signature is only meaningful if you trust the key that made it. DNSSEC builds that trust as a chain from the root of the DNS down to the individual name.

1. The root zone is signed. Its public key is the trust anchor, distributed with validating resolvers and treated as inherently trusted. This anchor is the foundation everything else hangs from.
2. The root zone publishes a DS record for each top-level domain such as .com. The DS record is a hash of that top-level domain's key. Because the root signed it, a resolver that trusts the root now trusts the .com key.
3. The .com zone in turn publishes a DS record for example.com, committing to that domain's key.
4. Finally, example.com signs its own records with the key the chain now vouches for.

Each parent vouches for its child by signing a fingerprint of the child's key. Follow the links from the root down and a resolver can confirm, at every step, that the key it is trusting was blessed by the level above. Break any link, a missing or wrong DS record, and validation fails at that point.

What DNSSEC does not do

This is where deployments go wrong, because the name suggests more than the protocol delivers.

• DNSSEC does not encrypt anything. Queries and answers still travel in the clear. Anyone watching the network sees which domains you look up. Signatures prove authenticity, not secrecy. For confidentiality you need encrypted transport, covered in DNS over HTTPS vs DNS over TLS.
• It protects data, not the last hop. DNSSEC validation typically happens at your resolver. The short path from your device to that resolver is usually unsigned, so a local attacker between you and the resolver is a separate problem that encrypted transport addresses.
• It only helps signed zones. If a domain's owner has not enabled DNSSEC, there is nothing to validate and answers for it stay forgeable.
• It only helps validating resolvers. If your resolver does not check signatures, all the signing in the world changes nothing for you.

Both sides have to participate. A signed zone queried through a non-validating resolver gets no protection, and a validating resolver querying an unsigned zone has nothing to verify.

There is also a gap in how far validation reaches. In most setups the recursive resolver does the checking, and it sends the verified answer to your device with a single flag saying the data was authenticated. The short hop from your device to the resolver is usually not signed, so an attacker sitting on that last stretch of network could strip or alter the flag. This is why serious deployments run validation as close to the client as possible, or pair DNSSEC with encrypted transport that protects the last hop as well. DNSSEC guarantees the data was genuine when the validating resolver checked it, not that nothing touched it afterward on an unprotected link.

The tradeoffs operators feel

DNSSEC is not free to run. Signatures make responses larger, which historically strained older DNS transport and can be abused for amplification if servers are misconfigured. Key rotation and expiry management are operational work, and a lapsed signature takes the zone offline for validating resolvers, returning SERVFAIL. That failure mode is the point, a broken signature must not resolve, but it means DNSSEC mistakes are outages rather than silent degradations. NIST SP 800-81-2 covers deployment carefully for this reason.

Walking through a validated lookup

It helps to follow a single query all the way down, because the chain of trust is easier to hold in your head as a sequence of concrete steps than as an abstract diagram. Suppose a validating resolver needs the address record for www.example.com and has nothing useful in its cache.

1. The resolver starts at the root. It already holds the root key-signing key as a built-in trust anchor, so it does not have to fetch or trust anything to begin. It asks a root server about .com and receives, among other things, a DS record for .com along with the RRSIG that signs it. The resolver checks that RRSIG against the root key it already trusts. If that check passes, the resolver now trusts the DS record, which is a hash commitment to the .com key-signing key.
2. The resolver queries a .com server for the DNSKEY set of the .com zone. It hashes the .com key-signing key it receives and compares that hash to the DS record the root just handed it. A match means the key it is holding really is the key the root vouched for. The .com zone is now trusted.
3. The resolver asks .com about example.com and receives a DS record for example.com, signed by the .com zone-signing key. Because the resolver now trusts .com, it trusts this DS record too. One more link is forged.
4. The resolver queries the example.com servers for that zone's DNSKEY set, hashes the key-signing key, and confirms it matches the DS record .com provided. The zone at the bottom of the path is now trusted.
5. Finally the resolver asks for the address record of www.example.com and receives it together with an RRSIG. It verifies that signature against the zone-signing key it just authenticated. If the signature is valid and unexpired, the resolver marks the answer as authenticated and returns it.

Every step has the same shape. A key the resolver already trusts either signs the next piece of data directly, or commits to a hash of the next key down. Nothing in the path is taken on faith except the one root key that ships with the resolver. If any single verification fails, the resolver stops and returns SERVFAIL rather than passing along an answer it cannot prove.

The worked example also shows why a forged answer cannot survive. An attacker who injects a fake address for www.example.com cannot produce a valid RRSIG for it, because signing requires the zone's private key, which the attacker does not have. The forged record arrives, fails signature verification, and is discarded. The attacker would need to break the signing key or corrupt the chain somewhere above the record, both of which are far harder than racing a plain DNS reply.

Detection signals

DNSSEC changes what a defender can see, both when it is working and when something is wrong. Concrete signals worth watching:

• A spike in SERVFAIL responses for one zone. Validating resolvers return SERVFAIL when a signature fails to verify. A sudden cluster of them tied to a single domain usually means an expired signature or a botched key rollover, and occasionally an active tampering attempt on the path between the resolver and the authoritative servers.
• The authenticated-data flag going missing. Answers validated by the resolver carry an AD flag. If responses that used to arrive with AD set start arriving without it, the resolver may have stopped validating, or something upstream is stripping DNSSEC data.
• DS and DNSKEY mismatches. Monitoring that hashes your published key-signing key and compares it to the DS record in the parent will catch a broken chain before users do. A mismatch means validation is failing for everyone, whether from a rollover mistake or an unauthorized change.
• Unexpected NSEC or NSEC3 responses. A rise in signed non-existence proofs for names you do expect to exist can indicate a zone-generation or publishing fault.
• Signature expiry approaching. RRSIG records carry an explicit expiry. Alerting when the nearest expiry falls inside your rollover window turns the single most common DNSSEC outage into a routine ticket instead of a surprise.

The theme is that DNSSEC makes integrity failures loud. Plain DNS fails silently by handing over a forged answer that looks fine. DNSSEC converts the same event into a visible SERVFAIL or a missing AD flag, which is exactly the kind of signal monitoring can act on.

Common misconceptions

DNSSEC attracts a specific set of misunderstandings, most of them rooted in the word security promising more than the protocol delivers.

• "DNSSEC encrypts my DNS traffic." It does not. Every query and answer is still visible on the wire. DNSSEC proves authenticity, and confidentiality is a separate job handled by encrypted transport.
• "Signing my zone protects my users." Signing protects people whose resolvers validate. It does nothing for your own browsing unless the resolver you query is itself validating. Signing and validating are two independent switches, and both have to be on for a given lookup to be protected.
• "DNSSEC stops all DNS attacks." It stops forged and altered answers for signed zones. It does not stop denial of service against your name servers, does not stop registrar-account takeover that changes your records at the source, and does not protect zones that are not signed.
• "A validated answer is a safe destination." DNSSEC proves the address came from the real zone owner. It says nothing about whether that address is malicious. A compromised zone can serve a perfectly valid, perfectly signed answer that points at an attacker's server.
• "DNSSEC and DNS over HTTPS are competitors." They solve different problems and compose cleanly. DNSSEC gives integrity of the data, encrypted transport gives privacy of the query and protects the last hop. Running both is the intended configuration.

How it evolved

The gap DNSSEC fills was understood almost as soon as DNS was deployed, but closing it took a long time. The original protocol was designed in an era when the network was small and largely trusted, and authenticity simply was not a design goal. Early standardization efforts produced a version of the extensions that proved difficult to operate at scale, particularly around proving that a name did not exist without leaking the full contents of a zone. The NSEC3 mechanism, which hashes names so a "does not exist" proof does not hand out a list of every record, came out of that operational experience.

The turning point was signing the root zone. Until the root was signed there was no single anchor for the whole chain of trust, and validating resolvers had to be configured with a patchwork of individual trust anchors for the zones they cared about. Signing the root gave the internet one anchor to distribute, which is why validating resolvers can ship with a single root key and follow the chain down to any signed zone from there. The public key ceremonies that manage that root key exist because it is the one piece the entire system depends on.

Adoption since then has been steady but uneven. Some top-level domains are fully signed and widely validated, while others lag. The practical upshot is the situation described earlier: DNSSEC is a partial deployment, and any unsigned zone or non-validating resolver quietly falls back to plain, forgeable DNS.

How to secure it

For domain owners and resolver operators:

1. Sign your zones. Enable DNSSEC at your DNS provider and publish the DS record with your registrar so the chain of trust reaches your domain. A signed zone with no DS record in the parent is not validated.
2. Enable validation on resolvers. Turn on DNSSEC validation in your recursive resolvers so forged answers are actually rejected. Signing without validating protects other people, not you.
3. Automate key management. Use automated key rotation and monitor signature expiry. Most DNSSEC outages come from expired signatures, not attacks.
4. Pair it with encrypted transport. Add DNS over TLS or DNS over HTTPS for the privacy DNSSEC does not provide, and to protect the last hop to your resolver.
5. Monitor with Certificate Transparency and DNS monitoring. Watch for unexpected changes to your zone and for certificates issued against your domains. See Certificate Transparency Explained.

DNSSEC gives DNS the one thing it lacked from the start: a way to prove an answer is genuine. It is a foundation other protections build on, from HTTPS to email authentication. Deploy it correctly, keep it paired with encrypted transport, and you remove one of the oldest and quietest ways to redirect users without them ever knowing. To see how forged infrastructure and lookalike domains feed real intrusions, browse our exploit intelligence dashboard.

Frequently asked questions

Does enabling DNSSEC slow down DNS resolution? There is some added cost. A validating resolver fetches extra records and performs signature checks, which adds work and a little latency on the first uncached lookup. In practice the checks are fast and the results are cached like any other DNS data, so the ongoing effect on users is small. The larger responses do consume more bandwidth and can strain older transport, which is one reason correct server configuration matters.

If I sign my zone, do my visitors need to do anything? No. Visitors do not configure DNSSEC themselves. The protection depends on the resolver they use validating signatures, which is a choice made by their operating system, network, or DNS provider. Signing your zone makes protection possible, and whether a given visitor receives it depends on their resolver.

What happens if my DNSSEC signatures expire? Validating resolvers will treat your zone as broken and return SERVFAIL for it, which makes the domain appear offline to anyone behind a validating resolver. This is the single most common DNSSEC outage. It is why automated key management and expiry monitoring are the core operational discipline of running a signed zone.

Can DNSSEC stop an attacker who has taken over my registrar account? No. If an attacker controls the account that manages your domain, they can change your records, and in many cases re-sign the zone or update the DS record, at the source. DNSSEC protects data in transit from forgery. It does not defend the authoritative side against an intruder who legitimately controls it. Strong registrar-account security is a separate and necessary control.

Is DNSSEC still worth deploying if adoption is only partial? Yes. Partial adoption means the protection is not universal, and it does not weaken the protection you get for your own signed zone from validating resolvers. Signing also lets other security mechanisms build on authenticated DNS, such as publishing records that constrain which certificate authorities may issue for your domain. The value grows as more of the ecosystem validates.

Why does a broken chain fail closed instead of falling back to plain DNS? Because failing open would erase the guarantee. If a validating resolver quietly accepted an unverifiable answer whenever the chain broke, an attacker could break the chain on purpose to force that fallback. Returning SERVFAIL on a verification failure is the design choice that makes the guarantee real, at the cost of turning DNSSEC mistakes into visible outages.

What is the difference between a key-signing key and a zone-signing key in practice? The key-signing key signs only the set of keys in your zone, and it is the key the parent commits to through the DS record. The zone-signing key signs the actual data records. The split exists so you can rotate the zone-signing key as often as you like without coordinating with the parent, while the key-signing key changes rarely and involves a slower DS update at the registrar. Operationally this means most of your routine rotation touches only the zone-signing key and never leaves your own zone.

Related guides

• DNS Spoofing Explained
• DNS over HTTPS vs DNS over TLS
• How HTTPS Works
• Certificate Transparency Explained