DNSSEC Explained

DNSSEC adds origin authentication and integrity to DNS. A validating resolver can verify that an answer was signed by the zone and linked through a chain of trusted delegations. It can also verify authenticated denial when a signed name or record type does not exist. DNSSEC does not hide the question, encrypt the response, or certify that the server named by DNS is safe.

The problem DNSSEC addresses

Traditional DNS responses are not inherently authenticated. A client matching a reply to a query is not the same as proving that the zone owner authorized its data. An attacker able to inject a convincing forged response could redirect traffic or claim that a record does not exist. DNSSEC lets zone operators sign record sets, and lets resolvers detect data that does not match those signatures.

The protection applies to DNS data. Applications still need protocols such as TLS to authenticate and encrypt their own connection. A correctly signed A record can point to a malicious or compromised web server; DNSSEC proves publication by the signed DNS zone, not benevolent intent.

Records and roles

A DNSKEY includes flags, protocol, algorithm and key material. A key tag is a short calculated identifier used to match related records; it is not itself a security strength rating. Operational setups often distinguish a key-signing key from a zone-signing key, although protocol validation follows signatures and configured trust rather than informal labels.

How a positive answer is validated

Suppose a validator asks for the A record of www.example.com. It receives the A record set and an RRSIG. It uses the zone’s DNSKEY to verify that signature. It then needs confidence in that DNSKEY: the parent .com zone publishes a DS record derived from the child key. The parent’s records are signed and linked upward in the same way until the chain reaches a locally configured trust anchor, normally the DNS root key.

This is a chain of trust rather than a single “DNSSEC enabled” bit. A signed child without a DS at its parent can provide signatures, but an ordinary validator has no authenticated delegation connecting those keys to the root. A DS with missing or mismatched child keys can make validating resolvers treat answers as bogus and fail resolution.

Secure, insecure and bogus

A validating resolver can classify an answer as secure when the signature chain validates. An unsigned delegation with no DS is insecure in the technical sense: the resolver has authenticated that no chain was asserted, then accepts ordinary unsigned data. Bogus means validation was expected but failed—for example because a signature expired, a DS no longer matches, or required signed data is missing.

These terms are easy to misread. “Insecure” does not necessarily mean an active attack, and “secure” does not mean the destination or its content is trustworthy. They describe DNSSEC validation status.

What the DNSSEC Checker observes

The DNSSEC Checker queries DNSKEY and DS records and explains their presence. Seeing both is consistent with a signed delegation, but record observation is not equivalent to independent cryptographic validation. Full validation must check RRSIG time windows and algorithms, authenticate denials, follow every delegation, and start from a trusted key.

A recursive resolver may already perform validation on behalf of the application, but a simple record display cannot infer every aspect of the resolver’s trust configuration. That is why the checker uses cautious language rather than declaring the entire chain valid.

Key rollovers and operational timing

DNSSEC changes require coordination with caches and sometimes the parent registry. During a key rollover, old and new keys or signatures may coexist so cached DS, DNSKEY and RRSIG data remain compatible. Removing an old key too quickly can break validation for resolvers holding earlier data. Operators plan transitions around record TTLs, signature lifetimes, publication delays and registrar processes.

Clock accuracy also matters because signatures have inception and expiration times. A zone can fail even with the right keys if signatures expire, are not yet valid, or are generated incorrectly. Monitoring should therefore test actual validation, not merely check whether DNSKEY exists.

DNSSEC is not encrypted DNS

DNSSEC responses are usually visible to networks between the client and resolver, and queries from the resolver to authoritative servers are also normally visible. DNS over HTTPS (DoH), DNS over TLS (DoT) and DNS over QUIC encrypt transport between specific participants. They do not by themselves authenticate the zone’s data through DNSSEC.

The two mechanisms can complement each other: encrypted transport can limit observation or modification on one network segment, while DNSSEC can authenticate signed data end to end through a validator. Neither prevents the resolver or authoritative server from seeing the names it handles.

What DNSSEC does not solve

• It does not encrypt DNS names or answers.
• It does not make a domain, website or downloaded file safe.
• It does not stop an authorized zone operator from publishing a harmful destination.
• It does not replace TLS certificate validation.
• It does not prevent denial-of-service attacks or every compromise of signing infrastructure.

Use the general DNS Lookup to inspect ordinary record values and read DNS Record Types Explained for the surrounding resolver model.