--- id: "dnssec" kind: "glossary-term" title: "DNSSEC" language: "en" category: "DNS and technical foundations" updated: "2026-10-10T10:28:55Z" canonical: "https://tldlog.com/glossary/dnssec/" translations: es: "https://tldlog.com/es/glosario/dnssec/" de: "https://tldlog.com/de/glossar/dnssec/" fr: "https://tldlog.com/fr/glossaire/dnssec/" it: "https://tldlog.com/it/glossario/dnssec/" pt-BR: "https://tldlog.com/pt/glossario/dnssec/" ru: "https://tldlog.com/ru/glossariy/dnssec/" zh-Hans: "https://tldlog.com/zh/cihui/dnssec/" --- # DNSSEC Domain Name System Security Extensions Extensions to the DNS that add digital signatures to DNS answers. The signatures let a resolver (the server that looks up names for users) check that an answer is genuine and was not changed on the way. Owners turn it on through their DNS host and registrar. DNSSEC adds digital signatures to the answers of the Domain Name System, so a computer can check that an answer comes from the owner of a domain and was not changed on the way. It does not hide anything and does not stop every attack. Turning it on needs the DNS provider, the registrar and the registry to work together. ## What DNSSEC protects against, in plain words When someone visits example.com, a resolver looks up its address. Without DNSSEC, an attacker who feeds the resolver a forged answer can send visitors to the wrong server. With DNSSEC, a validating resolver checks the signature and rejects the forgery. RFC 4033 (March 2005) defines what DNSSEC gives: proof of origin and integrity for DNS data. It gives no confidentiality, so answers stay readable, and no protection against denial of service attacks. It covers DNS answers only, not phishing or the takeover of a registrar account. RFC 9364 (February 2023) calls DNSSEC the best current practice for authenticating DNS data; whether to use it for a domain is the owner's decision. ## How the chain of trust works from the root to your domain A validating resolver starts from one key it already trusts: the trust anchor, which is the root zone's Key Signing Key, published by IANA. From there it follows a chain: 1. The root zone holds a signed DS record for .com. 2. That DS record matches a key in the .com zone, which lets the resolver verify the .com records, including the DS record for example.com. 3. That DS record matches example.com's key, which verifies the domain's own records. A signed zone whose parent holds no DS record is an "island of security": it cannot be validated from the root. An answer is secure when every signature checks, insecure when signed proof shows the parent holds no DS record for the zone, and bogus when expected signatures are missing, expired or unusable (RFC 4033). For a bogus answer, the resolver normally returns an error, SERVFAIL (RFC 4035). ## Keys and records: KSK, ZSK, DNSKEY, DS and RRSIG - **DNSKEY** records publish a zone's public keys. - **RRSIG** records hold the signatures, each valid only between a start date and an expiry date. - **DS** records sit in the parent zone and hold a key tag, an algorithm number and a digest of the child's key. - The **KSK** signs only the zone's set of keys, and the parent's DS record points to it. The **ZSK** signs everything else. RFC 6781 (December 2012) notes that validators treat both kinds of key alike: the split is operational, and some zones use one key for both roles. Proving that a name does not exist needs its own records. NSEC names the next existing name, which lets anyone list the whole zone ("zone walking"). NSEC3 (RFC 5155) hashes the names first, though it still reveals details such as the zone's size. ## Turning DNSSEC on: what the registrar, registry and DNS provider each do 1. The DNS provider signs the zone and publishes DNSKEY and RRSIG records. 2. The DS data, or the key data, goes to the registrar. 3. The registrar sends it to the registry over EPP with the secDNS extension (RFC 5910, May 2010), either as DS data or as key data from which the registry builds the DS record. 4. The registry publishes the DS record in the TLD zone. When the registrar is also the DNS provider, steps 1 to 3 are often one setting. For gTLDs, the 2013 Registrar Accreditation Agreement requires registrars to relay requests to add, remove or change key material to registries that support DNSSEC, using RFC 5910. The Base Registry Agreement (approved on 21 January 2024, current as of October 2026) requires gTLD registries to sign their zones and accept key material from child domains. ccTLD rules differ: check with the registrar or registry. There is also an automated route: the DNS provider publishes CDS and CDNSKEY records stating what the DS record should be, and some registries and registrars scan for them. RFC 8078 (March 2017) added a signal to remove DNSSEC; RFC 9615 (July 2024) lets the parent verify these records cryptographically before turning DNSSEC on. ## What can go wrong: expired signatures, key rollovers and changes of DNS provider - **Expired signatures.** RRSIG records not renewed in time make answers bogus. - **A DS record with no matching key.** RFC 6781 calls this "security lameness": the domain fails for every validating resolver, and the fix takes time to spread. A KSK change therefore needs the new DS record at the parent before the old key is removed. - **Changing DNS provider.** The old operator controls the keys. The best method is a coordinated key rollover. If the old operator does not cooperate, the DS record is removed, the name servers are changed, and once that has spread the new DS record is added. The domain is unsigned in between, which RFC 8078 prefers to validation failures. Short TTLs help. Failures appear as SERVFAIL for users of validating resolvers, while the domain may still work for everyone else. At the root, as of 9 October 2026, ICANN plans to replace the root KSK on 11 October 2026: KSK-2024 (key tag 38696) takes over from KSK-2017 (key tag 20326), which is to be revoked on 11 January 2027 and removed on 22 March 2027. This concerns operators of validating resolvers, who need the new trust anchor, not registrants. ## DNSSEC and encrypted DNS: how they differ DNSSEC signs the data so any resolver can check it, but everything stays readable. DNS over TLS (DoT) and DNS over HTTPS (DoH) encrypt the link between a user's device and the resolver, which protects privacy, but they do not prove that the data came from the zone owner. The two complement each other. ## Sources - [RFC 4033: DNS Security Introduction and Requirements](https://www.rfc-editor.org/rfc/rfc4033.txt) - [RFC 6781: DNSSEC Operational Practices, Version 2](https://www.rfc-editor.org/rfc/rfc6781.txt) - [RFC 5910: Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP)](https://www.rfc-editor.org/rfc/rfc5910.txt) - [DNSSEC Trust Anchors and Rollovers](https://www.iana.org/dnssec/files) - [ICANN Announces Next Major Internet Security Update](https://www.icann.org/resources/press-material/release-2026-05-20-en) ## related terms - [DS record](https://tldlog.com/glossary/ds-record/) - [DNSKEY record](https://tldlog.com/glossary/dnskey-record/) - [resolver](https://tldlog.com/glossary/resolver/) - [DNS](https://tldlog.com/glossary/dns/)