Content deleted Content added
Add reception section |
→Early deployments: bare url corrected |
||
| (19 intermediate revisions by 15 users not shown) | |||
Line 1:
{{
{{Security protocol}}
The '''Domain Name System Security Extensions''' ('''DNSSEC''')
==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]]. {{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/rfc9460/ | title=Service binding and parameter specification via the DNS (DNS SVCB and HTTPS RRS) }}</ref>
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}}
Line 53:
| 1 || [[RSA (algorithm)|RSA]]/[[MD5]] || || {{no|Must Not Implement}} || {{no|Must Not Implement}}
|-
| 3 || [[Digital Signature Algorithm|DSA]]/[[SHA-1]] || {{IETF RFC |
|-
| 5 || RSA/SHA-1 || {{IETF RFC | 3110}}|| {{no2|Not Recommended}} || {{yes|Required}}
Line 74:
|-
| 16 || [[Curve448|Ed448]] || {{Okay|Optional}} || {{partial|Recommended}}
|-
|17
| [[SM3 (hash function)|SM2SM3]]
| {{IETF RFC | 9563}}
| {{okay|Optional}}
| {{okay|Optional}}
|-
|23
|[[GOST]] R 34.10-2012
| {{IETF RFC | 9558}}
| {{okay|Optional}}
| {{okay|Optional}}
|}
Line 88 ⟶ 100:
| 2 || [[SHA-256]] || {{ IETF RFC |4509 }}|| {{yes|Required}} || {{yes|Required}}
|-
| 3 || [[GOST]] [[GOST (hash function)|R 34.
|-
| 4 || [[SHA-384]] || {{ IETF RFC |6605}}|| {{okay|Optional}} || {{partial|Recommended}}
|-
|5
|[[GOST]] [[Streebog|R 34.11-2012]]
| {{IETF RFC | 9563}}
| {{okay|Optional}}
| {{okay|Optional}}
|-
|6
| SM3
| {{IETF RFC | 9558}}
| {{okay|Optional}}
| {{okay|Optional}}
|}
Line 176 ⟶ 200:
The new protocols will enable additional assurances and constraints for the traditional model based on [[public key infrastructure]]. They will also enable ___domain holders to assert certificates for themselves, without reference to third-party [[certificate authority|certificate authorities]].
Support for DNSSEC stapled certificates was enabled in [[Google Chrome]] 14,<ref>{{cite web|url=http://www.imperialviolet.org/2011/06/16/dnssecchrome.html|title=ImperialViolet|access-date=2011-11-26}}</ref> but was later removed.<ref>{{cite web|url=https://git.chromium.org/gitweb/?p=chromium/chromium.git;a=commit;h=6a7172345e72d755d99c095eb3d4768f0f585344|title=chromium git|access-date=2013-03-09}}</ref> For [[Mozilla Firefox]], support was provided by an add-on<ref>{{cite web|url=https://www.dnssec-validator.cz/|title=DNSSEC/TLSA Validator}}</ref>
==History==
Line 216 ⟶ 240:
===Early deployments===
Early adopters include [[Brazil]] ([[.br]]), [[Bulgaria]] ([[.bg]]), [[Czech Republic]] ([[.cz]]), [[Namibia]] ([[.na]])<ref>{{cite web |first=Patrick |last=Myles | title=GNSO Activity Update for ccNSO Council meeting |date=25 September 2014 | url=https://ccnso.icann.org/
IANA publicly tested a sample signed root since June 2007. During this period prior to the production signing of the root, there were also several alternative trust anchors. The IKS Jena introduced one on January 19, 2006,<ref>[http://www.ripe.net/ripe/maillists/archives/dns-wg/2006/msg00053.html dns-wg archive: Signed zones list] {{webarchive |url=https://web.archive.org/web/20070305102531/http://www.ripe.net/ripe/maillists/archives/dns-wg/2006/msg00053.html |date=March 5, 2007 }}</ref> the [[Internet Systems Consortium]] introduced another on March 27 of the same year,<ref>[https://www.isc.org/node/62 ISC Launches DLV registry to kick off worldwide DNSSEC deployment] {{webarchive |url=https://web.archive.org/web/20081118020616/https://www.isc.org/node/62 |date=November 18, 2008 }}</ref> while [[ICANN]] themselves announced a third on February 17, 2009.<ref>[https://itar.iana.org/ Interim Trust Anchor Repository]</ref>
Line 227 ⟶ 251:
|author=Sean Michael Kerner
|access-date=2008-09-27
}}</ref> On June 23, 2010, 13 registrars were listed as offering DNSSEC records for .ORG domains.<ref>{{cite web
|url=http://www.pir.org/get/registrars?order=field_dnssec_value&sort=desc
|title=.ORG Registrar List — with DNSSEC enabled at the top
|access-date=2010-06-23
|archive-date=2010-06-12
|archive-url=https://web.archive.org/web/20100612212156/http://pir.org/get/registrars?order=field_dnssec_value&sort=desc
|url-status=dead
}}</ref>
Line 298 ⟶ 324:
The [[Quad9|Quad9 public recursive DNS]] has performed DNSSEC validation on its main 9.9.9.9 address since it was established on May 11, 2016. Quad9 also provides an alternate service which does not perform DNSSEC validation, principally for debugging.<ref>{{Cite web|url=https://www.quad9.net/faq/|title=Quad9 FAQ|website=Quad9|access-date=July 7, 2018}}</ref>
===Deployment in infrastructure===
In September 2023, Microsoft announced it would utilize DNSSEC (via [[DNS-based Authentication of Named Entities|DANE]]) to verify the authenticity of certificates during SMTP communications.<ref>{{Cite web |title=Implementing Inbound SMTP DANE with DNSSEC for Exchange Online Mail Flow |url=https://techcommunity.microsoft.com/t5/exchange-team-blog/implementing-inbound-smtp-dane-with-dnssec-for-exchange-online/ba-p/3939694 |access-date=2024-05-28 |website=TECHCOMMUNITY.MICROSOFT.COM |language=en}}</ref>
== Reception ==
Line 339 ⟶ 369:
==Tools==
[[File:Unbound 1.22.0 screenshot.webp|thumb|upright=1.2|Usage of DNSSEC in [[Unbound (DNS server)|Unbound]] (checking validation with <code>unbound-host</code>)]]
DNSSEC deployment requires software on the server and client side. Some of the tools that support DNSSEC include:
| |||