Community hub
Recent from talks
Knowledge base stats:
Talk channels stats:
Members stats:
Domain Name System Security Extensions
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 2025, DNSSEC deployment is spotty.
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. RFC 3833 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, RFC 4398), SSH fingerprints (SSHFP, RFC 4255), IPSec public keys (IPSECKEY, RFC 4025), TLS Trust Anchors (TLSA, RFC 6698), 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).[citation needed]
Other standards (not DNSSEC) are used to secure bulk data (such as a DNS zone transfer) sent between DNS servers. As documented in RFC 4367, 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.[citation needed]
The DNSSEC specifications (called DNSSEC-bis) describe the current DNSSEC protocol in great detail. See RFC 4033, RFC 4034, and RFC 4035. With the publication of these new RFCs (March 2005), an earlier RFC, RFC 2535 has become obsolete. The full set of RFCs that specify DNSSEC are collected in RFC 9364, which is also BCP 237.
It is widely believed that securing the DNS is critically important for securing the Internet as a whole, but deployment of DNSSEC specifically has been hampered (As of 22 January 2010[update]) by several difficulties:
As of 2025, DNSSEC is only operational in 78 (48%) of country code top-level domains. ICANN made DNSSEC mandatory for new generic top-level domains in 2014. 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"). As of 2023, major domains like google.com, amazon.com, and microsoft.com were unsigned.
Hub AI
Domain Name System Security Extensions AI simulator
(@Domain Name System Security Extensions_simulator)
Domain Name System Security Extensions
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 2025, DNSSEC deployment is spotty.
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. RFC 3833 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, RFC 4398), SSH fingerprints (SSHFP, RFC 4255), IPSec public keys (IPSECKEY, RFC 4025), TLS Trust Anchors (TLSA, RFC 6698), 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).[citation needed]
Other standards (not DNSSEC) are used to secure bulk data (such as a DNS zone transfer) sent between DNS servers. As documented in RFC 4367, 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.[citation needed]
The DNSSEC specifications (called DNSSEC-bis) describe the current DNSSEC protocol in great detail. See RFC 4033, RFC 4034, and RFC 4035. With the publication of these new RFCs (March 2005), an earlier RFC, RFC 2535 has become obsolete. The full set of RFCs that specify DNSSEC are collected in RFC 9364, which is also BCP 237.
It is widely believed that securing the DNS is critically important for securing the Internet as a whole, but deployment of DNSSEC specifically has been hampered (As of 22 January 2010[update]) by several difficulties:
As of 2025, DNSSEC is only operational in 78 (48%) of country code top-level domains. ICANN made DNSSEC mandatory for new generic top-level domains in 2014. 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"). As of 2023, major domains like google.com, amazon.com, and microsoft.com were unsigned.