Content deleted Content added
Rescuing 2 sources and tagging 0 as dead.) #IABot (v2.0.9.5 |
m Hyperlink some RFCs |
||
Line 6:
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]]. {{IETF 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 [[digital signature|digitally signed]].<ref>{{Cite IETF |last1=Herzberg |first1=Amir |last2=Shulman |first2=Haya |year=2014 |title=Retrofitting Security into Network Protocols: The Case of DNSSEC |url=https://ieeexplore.ieee.org/document/6756846 |journal=IEEE Internet Computing |volume=18 |issue=1 |pages=66–71 |doi=10.1109/MIC.2014.14 |s2cid=12230888 |issn=1089-7801}}</ref> 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 record]]s, {{IETF RFC|4398}}), [[Secure Shell|SSH]] fingerprints ([[SSHFP record|SSHFP]], {{IETF RFC|4255}}), [[IPSec]] public keys (IPSECKEY, {{IETF RFC| 4025}}), [[Transport Layer Security|TLS]] Trust Anchors ([[TLSA]], {{IETF RFC | 6698 }}), or Encrypted Client Hello (SVCB/HTTPS records for ECH <ref>{{cite IETF | url=https://datatracker.ietf.org/doc/
DNSSEC ''does not'' provide confidentiality of data; in particular, all DNSSEC responses are authenticated but not encrypted. DNSSEC ''does not'' protect against [[denial of service|DoS]] attacks directly, though it indirectly provides some benefit (because signature checking allows the use of potentially untrustworthy parties).{{citation needed|date=February 2013}}
Other standards (not DNSSEC) are used to secure bulk data (such as a [[DNS zone transfer]]) sent between DNS servers. As documented in {{IETF 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|date=February 2013}}
The DNSSEC specifications (called ''DNSSEC-bis'') describe the current DNSSEC protocol in great detail. See {{IETF RFC | 4033 }}, {{ IETF RFC | 4034}}, and {{ IETF RFC | 4035}}. With the publication of these new RFCs (March 2005), an earlier RFC, {{ IETF RFC | 2535 }} has become obsolete. The full set of RFCs that specify DNSSEC are collected in {{IETF RFC|9364}}, which is also [[Request_for_Comments#Best_Current_Practice|BCP]] 237.
It is widely believed<ref>Interview with Dan Kaminsky on DNSSEC (25 Jun 2009) [https://web.archive.org/web/20090628074022/http://searchsecurity.techtarget.com/news/interview/0,289202,sid14_gci1360143,00.html# Kaminsky interview: DNSSEC addresses cross-organizational trust and security]</ref> that securing the DNS is critically important for securing the Internet as a whole, but deployment of DNSSEC specifically has been hampered ({{As of|2010|January|22}}) by several difficulties:
| |||