DNSSEC Explainer
DNSSEC is a set of extensions that helps a DNS resolver check whether a domain name answer is authentic. DNS already helps turn a name into an address, but the original system was designed without a built-in way to prove that a response had not been altered along the way. DNSSEC adds digital signatures to DNS records so a validating resolver can detect forged or modified data when a domain has been configured correctly.
The key idea is not secrecy. DNSSEC does not hide the name a device asks for, and it does not encrypt the conversation between a device and its resolver. Instead, it creates a chain of trust. A domain’s authoritative DNS service signs selected records with a private key. The matching public key is published in DNS so that a resolver can check the signature before accepting the answer.
That checking can be linked upward through the DNS hierarchy. A parent zone can publish a record that identifies the public key used by a child zone. For example, the top-level .com zone can point toward the signed information for a participating .com domain. Resolvers that start with trusted root information can then verify each link down to the requested domain. This arrangement is why DNSSEC is often described as a chain of trust rather than as one central approval service.
Several DNS record types support the process. A DNSKEY record publishes a public key, an RRSIG record carries a signature for a set of records, and a DS record connects a child zone to its parent. Negative answers can be signed too, which helps a resolver distinguish between a name that truly does not exist and a false response claiming that it does not exist.
A validating resolver has three possible outcomes. It may receive a secure, correctly signed answer; an insecure answer from a zone that is not signed; or a bogus answer whose required signatures or trust links do not check out. A resolver configured to require validation can reject bogus data instead of using it. That behavior can protect people from certain DNS redirection attacks, but it also means a configuration mistake may make a reachable service appear unavailable.
DNSSEC needs careful operational work. Zone-signing keys must be stored and rotated correctly, signatures must be refreshed before they expire, and the DS record at the parent must match the child zone’s current key. Organizations also need to consider how DNSSEC interacts with content delivery networks, managed DNS providers, and emergency changes. The technology is reliable only when the technical and administrative steps remain aligned.
DNSSEC complements, rather than replaces, other protections. Encrypted DNS can reduce exposure of requests in transit, and HTTPS helps verify the website after a connection starts. DNSSEC focuses earlier in the path by helping validate the address information a domain publishes. Its central purpose is simple: give resolvers evidence that the DNS answer came from the proper authority and has not been silently changed.
DNSSEC adds digital signatures to DNS data. A resolver can use DNSKEY, RRSIG, and DS records to validate a signed answer through a chain of trust from the DNS root to the domain.
It helps a validating resolver detect forged DNS data, including a false address or a false claim that a name does not exist. It does not encrypt DNS queries or replace HTTPS.
Keys, signatures, and parent-zone links must agree. An expired signature, incorrect DS record, or failed key rollover can cause a validating resolver to reject a legitimate domain answer.
Explore more "Explainers"
Discover additional explainers across politics, science, business, technology, and other fields. Each explainer breaks down a complex idea into clear, everyday language—helping you better understand how major concepts, systems, and debates shape the world around us.