What Is DNSSEC? Domain Name Security, Explained

DNSSEC (Domain Name System Security Extensions) is a set of protocol extensions that adds cryptographic signatures to DNS records, letting a resolver verify that a DNS response actually came from the domain’s legitimate authority and wasn’t forged or altered along the way.

Why plain DNS needed this

DNS was designed in an era when the network was assumed trustworthy, so responses carry no built-in proof of authenticity. A resolver asks “what’s the IP address for this domain?” and trusts whatever answer comes back. That trust is exploitable: an attacker positioned on the network path, or one who can guess a query’s transaction ID, can inject a forged response before the real one arrives — a technique known as DNS cache poisoning or spoofing. Once a poisoned answer is cached, every subsequent lookup for that domain from that resolver returns the attacker’s IP address instead of the real one, silently redirecting traffic to a server the attacker controls.

This matters even for encrypted connections. If DNS resolution is compromised, a client can be routed to an attacker’s server before HTTPS or certificate validation ever gets a chance to catch the problem — though a valid TLS certificate check would still fail against an attacker who doesn’t hold the real domain’s private key, DNSSEC closes the gap earlier in the chain.

How it works

DNSSEC introduces a chain of digital signatures that mirrors the existing hierarchical structure of DNS itself, rooted in the same parent-to-child delegation from the root zone down to top-level domains and then individual domains.

• RRSIG records hold a digital signature over a set of DNS records, generated with the zone’s private key.
• DNSKEY records publish the zone’s public key, so resolvers can verify those signatures.
• DS records live in the parent zone and contain a hash of the child zone’s public key, forming the link in the chain of trust from parent to child.
• NSEC/NSEC3 records prove a domain name doesn’t exist, preventing an attacker from forging a “no such record” response to hide a real one.

A validating resolver walks this chain starting from the root: verify the root’s signature, use that to trust the top-level domain’s key, use that to trust the specific domain’s key, and finally verify the actual record’s signature with that key. If any signature in the chain fails to validate, the resolver rejects the response rather than passing it to the application — even if the record itself would otherwise look plausible.

What DNSSEC does and doesn’t protect

DNSSEC guarantees authenticity and integrity: the response came from the zone’s legitimate key holder and wasn’t modified in transit. It does not provide confidentiality — DNSSEC-signed queries and responses are still sent in plaintext, so anyone observing the traffic can see which domains are being looked up. That’s a separate problem addressed by protocols like DNS-over-HTTPS or DNS-over-TLS, which encrypt the query itself but don’t verify who signed the answer. The two are complementary, not substitutes for each other.

Enabling DNSSEC

Turning on DNSSEC for a domain requires action at two levels:

1. At the DNS host — the nameserver operator (often a managed DNS provider) generates signing keys and starts signing the zone’s records automatically.
2. At the registrar — the domain owner publishes a DS record at the registrar, which forwards it up to the parent zone. This is the step that actually links the domain into the global chain of trust; without it, a signed zone is just unverified extra data that resolvers ignore.

Most managed DNS and registrar services now support DNSSEC with a toggle in their dashboard rather than requiring manual key management, since key generation, rotation, and re-signing are handled behind the scenes.

The takeaway

DNSSEC adds a verifiable chain of cryptographic signatures to DNS, so a resolver can confirm a response really came from the domain’s authoritative source instead of trusting it blindly. It stops cache-poisoning and spoofing attacks that plain DNS has no defense against, though it leaves queries unencrypted — pair it with DNS-over-HTTPS or DNS-over-TLS if confidentiality matters too. Enabling it takes coordinated setup at both the DNS host and the registrar, but for domains handling anything security-sensitive, that one-time setup closes a gap that sits underneath every other layer of web security.