DNSSEC: what it actually protects — and what it doesn't
DNSSEC adds cryptographic signatures to DNS responses so a validating resolver can confirm an answer wasn't altered or forged in transit or in a cache, closing the gap that lets attackers forge DNS responses; it does not encrypt your DNS traffic, hide what domains you look up, or protect anything once the answer leaves a validating resolver and reaches your browser.
By AdminKit team, Netbase JSC · Updated October 24, 2026
The problem DNSSEC was built to fix
Ordinary DNS has no built-in way for a recursive resolver to tell a genuine answer from a forged one. A resolver asks “what’s the IP address for example.com?” and accepts whatever response arrives first that appears to match the query — there’s no signature, no proof the response actually came from the domain’s authoritative nameserver. RFC 4033 describes the consequence plainly: an attacker who can inject a forged response into the path between a resolver and the real authoritative server (or poison a resolver’s cache with one) can redirect anyone using that resolver to an address of their choosing, with no indication anything went wrong. This is the same structural weakness behind DNS cache-poisoning and some DNS hijacking scenarios described in our DNS hijacking guide.
DNSSEC fixes this by having each domain cryptographically sign its own DNS records. RFC 4034 defines the record types involved: a DNSKEY record publishes the domain’s public signing key, RRSIG records are the signatures over each set of records, and a chain of DS records at each parent zone (from the root down through the TLD to the domain) lets a resolver verify the whole chain of trust without needing to pre-trust every individual domain’s key out of band. A validating resolver checks this chain and only accepts an answer if the signature verifies — a forged or altered response fails validation and gets dropped instead of silently accepted.
What DNSSEC does not do
The most consequential misunderstanding about DNSSEC is treating it as encryption. It isn’t. DNSSEC signs answers so their authenticity can be checked; it does nothing to hide the contents of a query or response from anyone observing the network path. Your ISP, a coffee-shop Wi-Fi operator, or anyone else positioned to see your DNS traffic can still see exactly which domains you’re resolving, DNSSEC or not. If your goal is to keep DNS lookups private rather than just tamper-evident, that’s the job of DNS-over-HTTPS (DoH) or DNS-over-TLS (DoT), which encrypt the transport — a genuinely different problem with a genuinely different fix; see our guide on DoH vs DoT for how those compare.
DNSSEC also stops at the DNS answer. It verifies that the IP address you received for a hostname is the one the domain’s owner actually published — it has no opinion on what’s running at that IP address, whether its TLS certificate is valid, or whether the content served there is trustworthy. A domain can have flawless DNSSEC and still serve an expired or mismatched TLS certificate; those are separate checks covered in our guide on reading a TLS/SSL certificate check result.
And critically, DNSSEC only protects the hop between the authoritative server and a validating resolver. If the resolver you’re actually using doesn’t perform validation — many ISP and default router resolvers historically haven’t — a signed answer and a forged one are treated identically once they reach you, because nothing downstream of the resolver re-checks the signature.
How to check your own exposure
Two separate questions are worth answering, and conflating them is the most common DNSSEC mistake:
- Does the domain you’re checking publish signed records at all? Use AdminKit’s DNS lookup tool to inspect whether a domain has
DNSKEY/RRSIGrecords and aDSrecord at its parent zone. A domain with none of these isn’t using DNSSEC, full stop — there’s nothing to validate. - Does the resolver you actually use perform validation? A signed domain provides no protection if nothing downstream checks the signature. Test your resolver’s behavior with AdminKit’s DNS resolver test, and consult ICANN’s DNSSEC overview for how validating resolvers like most public DNS providers handle this today.
The operational tradeoff
DNSSEC’s biggest real-world risk isn’t a security weakness — it’s operational fragility. Signing keys need periodic rollover, and a rollover done incorrectly (old signatures expiring before new ones propagate, or a DS record at the parent zone falling out of sync with the domain’s own keys) can make every record in a signed zone fail validation simultaneously, taking the domain offline for anyone using a validating resolver — a worse outcome than not having DNSSEC at all. This operational cost, more than any technical limitation, is why adoption across both domains and resolvers remains uneven years after DNSSEC was standardized.
Related checks
DNSSEC, TLS certificate validity, and DNS-over-HTTPS/DoT each protect a different link in the chain between typing a domain name and loading a trustworthy page. See reading a TLS/SSL certificate check result for what happens after a DNS answer is accepted, and DNS rebinding explained for a related but distinct DNS-trust problem that DNSSEC does not address.
This guide is general information, not a security audit of your specific network — see our disclaimer for what AdminKit's guidance does and does not commit to.
Frequently asked questions
What problem does DNSSEC actually solve?
DNSSEC solves authenticity, not confidentiality: it lets a resolver cryptographically verify that a DNS answer really came from the domain's authoritative servers and wasn't modified along the way — including by cache-poisoning attacks that inject forged records into a resolver's cache. Without DNSSEC, a resolver has no way to tell a legitimate answer from a convincingly forged one; RFC 4033 sets out this exact threat model.
Does DNSSEC encrypt my DNS queries?
No. This is the single most common misconception about DNSSEC. It signs responses so they can be verified as authentic, but the queries and answers themselves travel in plaintext, exactly as with unsigned DNS — anyone on the network path can still see which domains you're looking up. If you want confidentiality rather than authenticity, that's what DNS-over-HTTPS (DoH) and DNS-over-TLS (DoT) provide, and they solve a different problem than DNSSEC solves.
If a domain has DNSSEC enabled, does that mean my connection to it is secure?
No — DNSSEC only validates the DNS answer, meaning it confirms you received the correct IP address for a hostname. It says nothing about whether the server at that IP address is trustworthy, whether its TLS certificate is valid, or whether the site itself is safe. Those are separate checks: see our guide on reading a TLS/SSL certificate check result for what happens after DNS resolution succeeds.
Why isn't DNSSEC universally deployed if it closes a real gap?
Deployment requires both the domain's authoritative DNS (signing every zone and managing key rollovers correctly) and the resolver doing the lookup (actually performing validation and rejecting unsigned or invalid answers) to support it, and a single misconfigured key rollover can take a signed domain completely offline for every validating resolver. That operational risk, combined with the fact that most resolvers still accept unsigned answers by default, has historically kept adoption uneven across both domains and resolver operators, as ICANN's and APNIC's public deployment tracking documents.
How do I check if DNSSEC is actually working for a domain?
You need to confirm two separate things: that the domain publishes signed records (DS record at the parent zone plus DNSKEY/RRSIG records at the domain itself), and that the resolver you're actually using performs validation and would reject a tampered answer. Use AdminKit's DNS lookup tool to inspect a domain's published records as a starting point for the first check.
Want AdminKit to watch this for you?
Free checks tell you the state today. Protective DNS and monitoring tell you when it changes.