DNS was designed in the early 1980s without security in mind. At the time, the internet was a small academic network where trust was assumed. The protocol that emerged – simple, fast, and lightweight – became the foundation of how every domain name resolves to an IP address. It also inherited a fundamental vulnerability: nothing in the original design verifies that the response you receive actually came from the authoritative source.
DNSSEC – DNS Security Extensions – is the solution to that problem. It adds cryptographic signatures to DNS records so that resolvers can verify the responses they receive are authentic and have not been tampered with in transit.
The problem DNSSEC solves
When your device sends a DNS query, the response travels over the network as plain data. A sufficiently positioned attacker can intercept that query and return a forged response – pointing your domain to an IP address they control rather than the one you configured. Your visitors’ browsers follow the DNS response, connect to the attacker’s server, and see whatever the attacker serves them. The domain in their browser bar still looks correct.
This attack is called DNS cache poisoning or DNS spoofing. It has been exploited in the real world to redirect users of legitimate banking sites, email services, and government portals to convincing fakes designed to steal credentials.
Cache poisoning works by injecting a false record into a resolver’s cache. Once a resolver has cached the forged record, every user relying on that resolver gets directed to the wrong IP until the TTL expires. A single successful injection can affect thousands or millions of users.
DNSSEC prevents this by allowing resolvers to verify the authenticity of every DNS response using cryptographic signatures. A forged response will fail signature verification and be rejected.
How DNSSEC works
DNSSEC uses public key cryptography to sign DNS records. The process involves several record types working together to establish a chain of trust from the DNS root down to your domain.
DNSKEY records
Each DNSSEC-enabled zone has one or more DNSKEY records. These contain the public keys used to verify the zone’s signatures. There are two key types:
Zone Signing Key (ZSK): Used to sign the actual DNS records in the zone (A records, MX records, etc.).
Key Signing Key (KSK): Used to sign the DNSKEY records themselves, including the ZSK. The KSK is the root of trust for the zone.
RRSIG records
Every DNS record set in a DNSSEC-signed zone has a corresponding RRSIG (Resource Record Signature) record. The RRSIG contains a digital signature over the record set, created using the Zone Signing Key.
When a resolver receives a DNS response, it also receives the corresponding RRSIG. It uses the public ZSK from the DNSKEY record to verify the signature. If the signature is valid, the record is authentic. If the signature does not verify, the response is rejected.
DS records
The DS (Delegation Signer) record is how the chain of trust works across zone boundaries. When your domain is signed, your registrar publishes a DS record in the parent zone (the TLD zone for .com domains, for example). The DS record contains a hash of your domain’s KSK.
When a resolver queries your domain, it retrieves your DNSKEY records and checks that the KSK matches the DS record published in the parent zone. If they match, the resolver trusts your zone’s signing keys. The parent zone’s DS record was itself verified against the grandparent zone, and so on up to the root.
The chain of trust
This is how DNSSEC’s trust model works end to end:
- The DNS root zone is signed with keys managed by ICANN. Resolvers have the root’s public key built in as a trust anchor.
- TLD zones (.com, .org, .net, etc.) are signed. The root zone contains DS records for each TLD’s signing key, creating a verifiable link.
- Your domain zone is signed. The TLD zone contains a DS record for your domain’s signing key.
- A resolver querying your domain verifies the chain: root trusts TLD, TLD trusts your domain, your domain’s records are signed with a verified key.
If any link in this chain fails – missing DS record, expired signature, key mismatch – the resolver cannot establish trust and treats the response as potentially forged.
What DNSSEC protects against and what it does not
DNSSEC solves a specific problem: it ensures the DNS responses you receive are authentic and come from the authoritative source. It does not encrypt DNS traffic – queries and responses are still transmitted in plaintext and can be observed by anyone on the network path. DNS-over-HTTPS (DoH) and DNS-over-TLS (DoT) address the privacy problem; DNSSEC addresses the integrity problem. They are complementary, not alternatives.
DNSSEC protects against:
- DNS cache poisoning attacks that inject forged records into resolvers
- Man-in-the-middle attacks that modify DNS responses in transit
- DNS hijacking that redirects traffic from a legitimate domain to an attacker-controlled server
DNSSEC does not protect against:
- A compromised authoritative nameserver (if the nameserver itself is hacked, it can serve any records it wants, signed with valid keys)
- Privacy concerns – your DNS queries are still visible to the resolver and anyone on the network path
- SSL/TLS attacks – DNSSEC verifies DNS resolution, not the connection to the server itself
For complete security, DNSSEC works alongside SSL/TLS, not as a replacement for it. A visitor to your site benefits from both: DNSSEC ensures they reach the correct server, and SSL/TLS ensures their connection to that server is encrypted and authenticated.
DNSSEC and web hosting
For website owners, DNSSEC has practical implications that go beyond abstract security theory.
Domain hijacking protection
Without DNSSEC, an attacker who successfully poisons a resolver’s cache can redirect your domain’s traffic to their own server. Visitors see your domain in the browser bar but land on a site controlled by someone else. With DNSSEC, resolvers that support validation will reject the forged response because it will not have a valid cryptographic signature.
Email security
DNSSEC is increasingly relevant to email authentication. DANE (DNS-based Authentication of Named Entities) is a protocol that uses DNSSEC to publish SSL certificate information in DNS, allowing email servers to verify certificates without relying on certificate authorities. DANE requires DNSSEC to function because it depends on the integrity of DNS records.
Search engine trust signals
While DNSSEC is not currently a direct Google ranking factor, it is part of the broader security posture that affects how search engines and browsers perceive domains. HTTPS, DNSSEC, and DMARC together signal that a domain owner takes security seriously.
Checking whether a domain has DNSSEC enabled
You can verify the DNSSEC status of any domain using SiteProbe’s DNSSEC checker. It validates the DNSKEY, DS, and RRSIG records for any domain and verifies the chain of trust from the root down to the domain’s zone.
What the checker looks for:
- DNSKEY records present – the zone has signing keys published
- DS record in parent zone – the registrar has published the delegation signer record linking your zone to the parent
- RRSIG records valid – the signatures on DNS records are current and verify correctly against the published keys
- Chain of trust intact – the link from root to TLD to domain is unbroken
A domain with DNSSEC fully configured will show all of these as valid. A domain with partial DNSSEC configuration (keys published but no DS record, for example) will show as broken – which is actually worse than no DNSSEC at all, because DNSSEC-validating resolvers will refuse to resolve the domain entirely if the chain is broken.
Common DNSSEC failure states:
No DNSSEC – the domain has no DNSKEY records. DNSSEC-validating resolvers treat it as an unsigned zone and resolve it normally without validation. No protection, but no breakage.
Signed zone, no DS record – the domain has DNSKEY and RRSIG records but the registrar has not published the DS record in the parent zone. DNSSEC-validating resolvers cannot establish the chain of trust. Depending on resolver behavior, this may cause resolution failures.
Expired signatures – RRSIG records have a validity period. If the zone operator does not re-sign before signatures expire, resolvers reject the records as potentially tampered. This causes real resolution failures affecting real visitors.
Key rollover not completed – changing DNSSEC keys requires a careful process where the old and new keys coexist for a period. If the rollover is done incorrectly or the DS record is updated before resolvers have cached the new DNSKEY, the chain breaks. This is one of the most common causes of DNSSEC-related outages.
How to enable DNSSEC for your domain
Enabling DNSSEC is a two-step process involving both your DNS provider (who manages your zone) and your domain registrar (who manages the DS record in the parent zone).
Step 1: Sign your zone
Your DNS hosting provider needs to sign your zone with DNSSEC. Many DNS providers support this with a one-click option in their control panel. When you enable DNSSEC signing, the provider:
- Generates a ZSK and KSK for your zone
- Signs all DNS records with the ZSK
- Signs the DNSKEY records with the KSK
- Publishes DNSKEY and RRSIG records in your zone
At this point your zone is signed, but the chain of trust is not yet complete.
Step 2: Publish the DS record at your registrar
Your registrar needs to publish a DS record in the parent TLD zone that links to your zone’s KSK. Your DNS provider will give you the DS record data – typically a key tag, algorithm number, digest type, and digest value.
Log into your domain registrar’s control panel and find the DNSSEC settings for your domain. Enter the DS record data provided by your DNS provider. The registrar publishes this to the TLD zone, completing the chain of trust.
Once both steps are complete, DNSSEC-validating resolvers can verify the full chain from root to your domain.
Important: key rollover
DNSSEC keys should be rotated periodically. Most DNS providers that support DNSSEC handle key rollovers automatically – they follow the correct procedure of pre-publishing new keys before the old ones expire and updating the DS record at the registrar. If your provider does not automate this, you need to manage rollovers manually, which is operationally complex and a common source of DNSSEC outages.
Verifying your DNSSEC configuration after setup
After enabling DNSSEC, verify the complete chain using tools.hostney.com/dnssec. Check that:
- DNSKEY records are present and match what your DNS provider published
- The DS record in the parent zone matches your KSK
- RRSIG records are present on your DNS records
- Signatures have not expired and will not expire soon
- The chain of trust validates from root to your domain
Run this check again any time you make DNS changes, renew your domain, or after a key rollover to ensure the configuration remains intact.
DNSSEC adoption
Despite its benefits, DNSSEC adoption has been slow. As of 2025, roughly 20-25% of .com domains have DNSSEC enabled, and not all resolvers perform DNSSEC validation even when it is configured. The operational complexity of key management, the risk of outages from misconfiguration, and the relatively narrow attack surface that DNSSEC addresses (cache poisoning is real but less common than phishing or malware) have all contributed to slow adoption.
That said, adoption is growing. DNSSEC is required for certain government and financial sector domains in many countries. DNS-over-HTTPS adoption is increasing, and DANE interest is growing alongside it, both of which benefit from or require DNSSEC.
For most website owners, the calculus is: DNSSEC adds meaningful protection against a real attack vector, costs nothing if your DNS provider handles it automatically, and requires ongoing operational attention if it does not. If your registrar and DNS provider both support automated DNSSEC with automatic key rollovers, enabling it is worth doing. If management is manual, evaluate whether the operational overhead is justified for your threat model.
Summary
DNSSEC adds cryptographic signatures to DNS records so that resolvers can verify responses are authentic and have not been tampered with. It protects against DNS cache poisoning and traffic hijacking by establishing a verifiable chain of trust from the DNS root down to your domain’s zone. Enabling it requires signing your zone through your DNS provider and publishing a DS record through your registrar. A misconfigured or partially deployed DNSSEC setup can cause resolution failures, so verifying the complete chain of trust with tools.hostney.com/dnssec after setup and after any DNS changes is essential. DNSSEC addresses integrity, not privacy – it works alongside SSL/TLS and DNS-over-HTTPS rather than replacing them.