Standard DNS has no way to verify that responses are genuine — a 40-year design gap that enables cache poisoning, spoofing, and man-in-the-middle attacks. DNSSEC closes that gap with cryptographic signatures. Here is how it works and how to deploy it correctly.
Security Gap: Without DNSSEC, any resolver on the path between a user and your authoritative server can inject a forged response — redirecting traffic to attacker-controlled infrastructure while the user sees the correct domain name in the browser. This is not theoretical; cache poisoning attacks are active and well-documented.
DNS was designed in 1983 when the internet was a research network of trusted peers. The protocol had one job: translate a human-readable name into a numeric IP address. There was no authentication mechanism — a resolver accepts whatever answer it receives, from whoever sends it first.
By the late 1990s, this gap was being actively exploited. Researchers demonstrated that a single forged UDP packet — sent at the right moment — could poison a resolver's cache, causing every user of that resolver to be redirected to a malicious server for hours. The attack worked because there was no way to distinguish a genuine DNS reply from a forged one.
DNSSEC, standardised in RFC 4033–4035 (2005), closes this gap. It does not replace DNS — it extends DNS with a public-key infrastructure layered on top of the existing protocol. Every DNS record set can now carry a cryptographic signature (RRSIG) that a validating resolver checks before accepting an answer.
An attacker floods a resolver with forged replies for a target domain. The resolver caches the fake IP; every user who queries that resolver gets the wrong answer until the TTL expires. At scale, this can redirect millions of users. With DNSSEC validation enabled at the resolver, each reply must carry a valid RRSIG — a forged reply has no valid signature and is silently dropped.
A forged reply redirects a user to an attacker-controlled server — one that may serve a pixel-perfect copy of your site to harvest credentials. With DNSSEC, a validating resolver rejects any reply whose signature does not match the zone's published DNSKEY record. The attacker cannot forge a valid signature without access to the private key.
An attacker fabricates an NXDOMAIN (domain-not-found) response for a real domain, blocking users from reaching it. Without DNSSEC, a resolver has no way to verify that the NXDOMAIN is genuine. NSEC and NSEC3 records solve this: they cryptographically prove which names do and do not exist in a zone, making forged non-existence responses verifiably invalid.
An attacker who compromises a registrar account can update NS records, redirecting all DNS traffic to their own servers. DNSSEC does not prevent the compromise itself — but it significantly limits propagation, because downstream resolvers that validate DNSSEC will reject responses from the hijacked servers, whose answers won't carry valid signatures from your original KSK.
The zone's public key, published as a DNS record. A zone typically publishes two: the Key Signing Key (KSK), used to sign only the DNSKEY record set, and the Zone Signing Key (ZSK), used to sign all other record sets. Resolvers retrieve the DNSKEY record and use it to verify RRSIG records.
A digital signature covering a specific record set (RRset) in the zone. Every record type — A, AAAA, MX, TXT, CNAME — gets its own RRSIG. The signature is computed with the zone's private ZSK and can be verified by anyone with the public DNSKEY. RRSIG records carry an expiry timestamp, so old signatures cannot be replayed.
A hash of the child zone's KSK, published in the parent zone (your TLD's zone). The DS record is what chains the child zone to the parent — it tells a resolver 'trust the key whose hash matches this DS record.' Without the DS record at your registrar, your DNSSEC deployment is technically complete but functionally invisible: resolvers cannot build the chain of trust.
The root DNS zone ('.') is signed and its trust anchors are hardcoded into all major resolvers. Each TLD (.com, .in, .org) is signed, with DS records in the root zone. Each signed domain has its DS record in its TLD zone. A resolver walks this chain — root → TLD → zone — verifying each link before accepting an answer.
NSEC (Next Secure) records prove authenticated non-existence: they list the next name in the zone's alphabetical order, allowing a resolver to verify that no names exist between two consecutive entries. NSEC3 adds hash obfuscation to prevent zone enumeration — an attacker cannot walk NSEC3 records to discover all names in your zone.
ZSKs are rotated frequently (every 30–90 days) because they sign a high volume of records. KSKs are rotated rarely (annually or less) because each rollover requires coordinating a new DS record with your registrar — a manual step that can break the chain of trust if not handled carefully. Most DNSSEC implementations automate ZSK rollover; KSK rollover should be planned and tested.
The most common misconception about DNSSEC is that it encrypts DNS traffic. It does not. DNSSEC provides authenticity and integrity — it proves an answer came from the right source and was not tampered with. DNS over HTTPS (DoH) and DNS over TLS (DoT) provide confidentiality — they hide the content of your queries from observers on the network path. The two solve different problems and are designed to be deployed together.
"DNSSEC tells you the answer is genuine. DoH/DoT ensures no one can read the question. You need both."
| Feature | DNSSEC | DoH / DoT |
|---|---|---|
| Primary purpose | Authenticity + integrity | Confidentiality |
| Protects against | Forged DNS answers | Eavesdropping on queries |
| Encrypts traffic? | No | Yes |
| Prevents MITM? | Yes (forged responses rejected) | Partial (hides query target) |
| Deployed at | Authoritative server + resolver | Recursive resolver or stub |
| Complementary? | Yes — pair with DoH/DoT | Yes — pair with DNSSEC |
| Capability | DNSSEC | DoH/DoT | DNS Firewall | HTTPS (TLS) |
|---|---|---|---|---|
| Prevents forged DNS answers | ✓ | ✗ | Partial | ✗ |
| Encrypts DNS queries | ✗ | ✓ | ✗ | ✗ |
| Blocks malicious domains | ✗ | ✗ | ✓ | ✗ |
| Encrypts data in transit | ✗ | Partial | ✗ | ✓ |
| Verifies domain ownership | ✓ | ✗ | ✗ | Partial |
| Works at authoritative layer | ✓ | ✗ | ✗ | ✗ |
"We serve regulated customers. An unauthenticated DNS path is a reportable risk under DPDP Act 2023. DNSSEC is a foundational control that should have been in place years ago."
For regulated enterprises — BFSI, healthcare, government — unauthenticated DNS is increasingly cited in security audits and is expected as a baseline control by CERT-In and sector regulators.
"Our SaaS product relies on API endpoints. If DNS for those endpoints can be spoofed, our customers could be connecting to attacker-controlled infrastructure — and our logs would show nothing."
Any organisation serving APIs, handling authentication endpoints, or operating SaaS platforms faces meaningful risk from DNS spoofing. DNSSEC eliminates the attack surface at the protocol layer.
"Our brand trust is everything. If a DNS attack redirects our site to a phishing page, the reputational damage outlasts the attack by years — especially with enterprise buyers who have long memories."
Brand trust is at risk when DNS can be manipulated. DNSSEC is also increasingly evaluated as a trust signal by enterprise procurement and security review teams.
DNSSEC deployment is straightforward on modern DNS infrastructure. The most common failure mode is not a technical error — it is stopping at step 5 and never completing the registrar submission in step 6, leaving the chain of trust incomplete.
Create a KSK (Key Signing Key) and ZSK (Zone Signing Key) for each zone using your DNS server software (BIND, PowerDNS, Unbound) or your DNS provider's DNSSEC tooling. Use RSA-2048 or ECDSA P-256 as a minimum. Store private keys in hardware security modules (HSMs) where key material is too sensitive for software storage.
Run zone signing to produce RRSIG records for every record set in the zone, plus NSEC3 records for authenticated denial of existence. Set signature validity periods appropriately — too short and you risk expired signatures during key rollover; too long and a compromised key has a longer window of exposure.
Add the zone's public DNSKEY record to your authoritative DNS server. This is the record resolvers will use to verify your RRSIG signatures. Confirm that your DNS server is serving the DNSKEY record correctly using dig +dnssec before proceeding.
The DS record is a hash of your KSK, and it must be published in the parent zone (your TLD's zone) by your registrar. This is the step most commonly skipped or mishandled. Without it, no validating resolver can build the chain of trust from the root to your zone. Your deployment is technically complete but functionally ineffective until this step is done.
Confirm end-to-end validation from the root to your domain before relying on the protection.
Configure automated ZSK rotation (every 30–90 days) using your DNS software's built-in rollover support. Plan KSK rollover (annual or less) as a coordinated exercise: the new KSK must be submitted to your registrar before the old one is retired. Test rollover procedures in a staging environment — a failed KSK rollover that breaks the chain of trust will cause DNSSEC-validating resolvers to reject all answers from your zone.
Swaran Soft provides end-to-end DNSSEC implementation as part of our DNS security posture service — covering everything from the initial zone inventory through registrar coordination, automated key management, and ongoing monitoring.
"Every enterprise we audit has at least one domain that handles sensitive traffic with no DNSSEC. It is always the domain they forgot — a legacy API endpoint, an internal tool, a subsidiary's site. Attackers do not forget."
We audit your full domain inventory, identify unsigned zones and misconfigured DNSSEC deployments, and deliver a prioritised remediation plan — at no cost.
Get a personalised assessment of your domain's DNSSEC posture, including any unsigned zones or misconfigured deployments.
AI Architect and Entrepreneur building India's Edge AI ecosystem. 25+ years in enterprise technology. Founder of Swaran Soft, Gignaati, and Copilots.in.