The Domain Name System Security Extensions (DNSSEC) is a suite of extension specifications by the Internet Engineering Task Force (IETF) for securing data exchanged in the Domain Name System (DNS) in Internet Protocol (IP) networks. The protocol provides cryptographic authentication of data, authenticated denial of existence, and data integrity, but not availability or confidentiality. As of 2026, DNSSEC deployment is spotty.
Overview The original design of the Domain Name System did not include any security features. It was conceived only as a scalable distributed system. The Domain Name System Security Extensions (DNSSEC) attempt to add security, while maintaining backward compatibility. of 2004 documents some of the known threats to the DNS, and their solutions in DNSSEC.
DNSSEC was designed to protect applications using DNS from accepting forged or manipulated DNS data, such as that created by DNS cache poisoning. All answers from DNSSEC protected zones are digitally signed. By checking the digital signature, a DNS resolver is able to check if the information is identical (i.e. unmodified and complete) to the information published by the zone owner and served on an authoritative DNS server. While protecting IP addresses is the immediate concern for many users, DNSSEC can protect any data published in the DNS, including text records (TXT) and mail exchange records (MX), and can be used to bootstrap other security systems that publish references to cryptographic certificates stored in the DNS such as Certificate Records (CERT records, ), SSH fingerprints (SSHFP, ), IPsec public keys (IPSECKEY, ), TLS Trust Anchors (TLSA, ), or Encrypted Client Hello (SVCB/HTTPS records for ECH).
DNSSEC does not provide confidentiality of data; in particular, all DNSSEC responses are authenticated but not encrypted. DNSSEC does not protect against DoS attacks directly, though it indirectly provides some benefit (because signature checking allows the use of potentially untrustworthy parties).
Other standards (not DNSSEC) are used to secure bulk data (such as a DNS zone transfer) sent between DNS servers. As documented in , some users and developers make false assumptions about DNS names, such as assuming that a company's common name plus ".com" is always its domain name. DNSSEC cannot protect against false assumptions; it can only authenticate that the data is truly from or not available from the domain owner.
The DNSSEC specifications (called DNSSEC-bis) describe the current DNSSEC protocol in great detail. See , , and . With the publication of these new RFCs (March 2005), an earlier RFC, has become obsolete. The full set of RFCs that specify DNSSEC are collected in , which is also BCP 237.
It is widely believedInterview with Dan Kaminsky on DNSSEC (25 Jun 2009) Kaminsky interview: DNSSEC addresses cross-organizational trust and security that securing the DNS is critically important for securing the Internet as a whole, but deployment of DNSSEC specifically has been hampered () by several difficulties: The need to design a backward-compatible standard that can scale to the size of the Internet Prevention of "zone enumeration" where desired Deployment of DNSSEC implementations across a wide variety of DNS servers and resolvers (clients) Disagreement among implementers over who should own the top-level domain root keys Overcoming the perceived complexity of DNSSEC and DNSSEC deployment
Adoption As of March 2026, DNSSEC is only operational in 83 (45%) of country code top-level domains. ICANN made DNSSEC mandatory for new generic top-level domains in 2014.DNSSEC en IPv6 vanaf 2014 verplicht bij ICANN Not all lower-level domains use DNSSEC. Verisign reported about 5% adoption in .net second-level domains and about 4% in .com. Second-level domain adoption exceeds 50% in .nl (Netherlands), .cz (Czech Republic), .no (Norway), .se (Sweden), and .nu (Niue, but used to sound like "new").Majority of Dutch domains and internet users have DNSSEC security As of 2023, major domains like google.com, amazon.com, and microsoft.com were unsigned.
Operation DNSSEC works by digitally signing records for DNS lookup using public-key cryptography. The correct DNSKEY record is authenticated via a chain of trust, starting with a set of verified public keys for the DNS root zone which is the trusted third party. Domain owners generate their own keys, and upload them using their DNS control panel at their domain-name registrar, which in turn pushes the keys via secDNS to the zone operator (e.g., Verisign for .com) who signs and publishes them in DNS.
Resource records DNS is implemented by the use of several resource records. To implement DNSSEC, several new DNS record types were created or adapted to use with DNSSEC: RRSIG (resource record signature) Contains the DNSSEC signature for a record set. DNS resolvers verify the signature with a public key, stored in a DNSKEY record. DNSKEY Contains the public key that a DNS resolver uses to verify DNSSEC signatures in RRSIG records. DS (delegation signer) Holds the name of a delegated zone. References a DNSKEY record in the sub-delegated zone. The DS record is placed in the parent zone along with the delegating NS records. NSEC (next secure record) Contains a link to the next record name in the zone and lists the record types that exist for the record's name. DNS resolvers use NSEC records to verify the non-existence of a record name and type as part of DNSSEC validation. NSEC3 (next secure record version 3) Contains links to the next record name in the zone (in hashed name sorting order) and lists the record types that exist for the name covered by the hash value in the first label of the NSEC3 record's own name. These records can be used by resolvers to verify the non-existence of a record name and type as part of DNSSEC validation. NSEC3 records are similar to NSEC records, but NSEC3 uses cryptographically hashed record names to avoid the enumeration of the record names in a zone. NSEC3PARAM (next secure record version 3 parameters) Authoritative DNS servers use this record to calculate and determine which NSEC3 records to include in responses to DNSSEC requests for non-existing names/types.
When DNSSEC is used, each answer to a DNS lookup contains an RRSIG DNS record, in addition to the record type that was requested. The RRSIG record is a digital signature of the answer DNS resource record set. The digital signature is verified by locating the correct public key found in a DNSKEY record. The NSEC and NSEC3 records are used to provide cryptographic evidence of the non-existence of any Resource Record (RR). The DS record is used in the authentication of DNSKEYs in the lookup procedure using the chain of trust. NSEC and NSEC3 records are used for robust resistance against spoofing.
Algorithms
DNSSEC was designed to be extensible so that as attacks are discovered against existing algorithms, new ones can be introduced in a backward-compatible fashion as described in . The following table, as of September 2026, defines the security algorithms to be used as published by IANA:
Algorithm field Algorithm Source DNSSEC Signing DNSSEC Validation 1 RSA/MD5 3 DSA/SHA-1 5 RSA/SHA-1 6 DSA-NSEC3-SHA1 7 RSASHA1-NSEC3-SHA1 8 RSA/SHA-256 10 RSA/SHA-512 12 GOST R 34.10-2001 13 ECDSA P-256/SHA-256 14 ECDSA P-384/SHA-384 15 Ed25519 16 Ed448 17 SM2SM3 18 ML-DSA-44 draft-westerbaan-dnssec-mldsa-04 23GOST R 34.10-2012
Digest field Digest Source DNSSEC Delegation DNSSEC Validation 1 SHA-1 2 SHA-256 3 GOST R 34.11-1994 4 SHA-384 5GOST R 34.11-2012 6 SM3
The lookup procedure From the results of a DNS lookup, a security-aware DNS resolver can determine whether the authoritative name server for the domain being queried supports DNSSEC, whether the answer it receives is secure, and whether there is some sort of error. The lookup procedure is different for recursive name servers such as those of many ISPs, and for stub resolvers such as those included by default in mainstream operating systems. Microsoft Windows uses a stub resolver, and Windows Server 2008 R2 and Windows 7 in particular use a non-validating but DNSSEC-aware stub resolver.
Recursive name servers Using the chain of trust model, a Delegation Signer (DS) record in a parent domain (DNS zone) can be used to verify a DNSKEY record in a subdomain, which can then contain other DS records to verify further subdomains. Say that a recursive resolver such as an ISP name server wants to get the IP addresses (A record and/or AAAA records) of the domain "www.example.com".
The process starts when a security-aware resolver sets the "DO" ("DNSSEC OK") flag bit in a DNS query. Since the DO bit is in the extended flag bits defined by Extension Mechanisms for DNS (EDNS), , all DNSSEC transactions must support EDNS. EDNS support is also needed to allow for the much larger packet sizes that DNSSEC transactions require. When the resolver receives an answer via the normal DNS lookup process, it then checks to make sure that the answer is correct. Ideally, the security-aware resolver would start with verifying the DS and DNSKEY records at the DNS root. Then it would use the DS records for the "com" top-level domain found at the root to verify the DNSKEY records in the "com" zone. From there, it would see if there is a DS record for the "example.com" subdomain in the "com" zone, and if there were, it would then use the DS record to verify a DNSKEY record found in the "example.com" zone. Finally, it would verify the RRSIG record found in the answer for the A records for "www.example.com".
There are several exceptions to the above example.
First, if "example.com" does not support DNSSEC, there will be no RRSIG record in the answer and there will not be a DS record for "example.com" in the "com" zone. If there is a DS record for "example.com", but no RRSIG record in the reply, something is wrong and maybe a man in the middle attack is going on, stripping the DNSSEC information and modifying the A records. Or, it could be a broken security-oblivious name server along the way that stripped the DO flag bit from the query or the RRSIG record from the answer. Or, it could be a configuration error.
Next, it may be that there is not a domain name named "www.example.com", in which case instead of returning a RRSIG record in the answer, there will be either an NSEC record or an NSEC3 record. These are "next secure" records that allow the resolver to prove that a domain name does not exist. The NSEC/NSEC3 records have RRSIG records, which can be verified as above.
Finally, it may be that the "example.com" zone implements DNSSEC, but either the "com" zone or the root zone do not, creating an "island of security" which needs to be validated in some other way. , deployment of DNSSEC to root is completed. The .com domain was signed with valid security keys and the secure delegation was added to the root zone on 1 April 2011.
Stub resolvers Stub resolvers are "minimal DNS resolvers that use recursive query mode to offload most of the work of DNS resolution to a recursive name server." An earlier definition was given in an earlier RFC: A stub resolver will simply forward a request to a recursive name server, and use the Authenticated Data (AD) bit in the response as a "hint to find out whether the recursive name server was able to validate signatures for all of the data in the Answer and Authority sections of the response." Microsoft Windows uses a stub resolver, and Windows Server 2008 R2 and Windows 7 in particular use a non-validating but AD-bit-aware stub resolver.