Domain Name System Security Extensions: Difference between revisions

Revision as of 04:18, 4 November 2024

Latest revision as of 18:52, 8 August 2025

(10 intermediate revisions by 8 users not shown)

Line 1:

{{shortShort description|Suite of IETF specifications for securing certain kinds of information provided by DNS}}

{{Security protocol}}

The '''Domain Name System Security Extensions''' ('''DNSSEC''') is a suite of [[Extension Mechanisms for DNS|extension]] specifications by the [[Internet Engineering Task Force]] (IETF) for securing data exchanged in the [[Domain Name System]] ([[DNS hijacking|DNS]]) in [[Internet Protocol]] ([[IPv6|IP]]) [[Networks and States|networks]]. The protocol provides [[message authentication|cryptographic authentication]] of data, [[SOCKS|authenticated]] denial of existence, and data [[Information_security#Integrity|integrity]], but not [[Information_security#Availability|availability]] or [[Information_security#Confidentiality|confidentiality]].

==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> <ref>{{cite IETF | url=https://datatracker.ietf.org/doc/draft-ietf-tls-esni/ | title=TLS Encrypted Client Hello }}</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 | 2539}}|| {{no|Must Not Implement}} || {{no|Must Not Implement}}

|-

| 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.1011-20011994]] || {{ IETF RFC | 5933 }}|| {{no|Must Not Implement}} || {{okay|Optional}}

|-

| 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> whileup nativeto supportFirefox is56, currentlywhile awaitingnative someonesupport towas startproposed workingbut onultimately itrejected.<ref>[https://bugzilla.mozilla.org/show_bug.cgi?id=672600 Bugzilla@Mozilla: Bug 672600 - Use DNSSEC/DANE chain stapled into TLS handshake in certificate chain validation]</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/desites/nodedefault/7603files/filefield_46433/gnso-25sep14-en.pdf {{Bare URL PDF| access-date=March 20222025-08-08}}</ref> [[Puerto Rico]] ([[.pr]]) and [[Sweden]] ([[.se]]), who use DNSSEC for their [[country code top-level ___domain]]s;<ref name="EPIC-20080527">Electronic Privacy Information Center (EPIC) (May 27, 2008). [http://epic.org/privacy/dnssec/ DNSSEC]<!--access-date=2008-06-13--></ref> [[RIPE NCC]], who have signed all the reverse lookup records (in-addr.arpa) that are delegated to it from the [[Internet Assigned Numbers Authority]] (IANA).<ref>[http://www.ripe.net/docs/ripe-359.html RIPE NCC DNSSEC Policy] {{webarchive |url=https://web.archive.org/web/20071022171800/http://www.ripe.net/docs/ripe-359.html |date=October 22, 2007 }}</ref> [[ARIN]] is also signing their reverse zones.<ref>[https://www.arin.net/resources/dnssec/ ARIN DNSSEC Deployment Plan]</ref> In February 2007, [[TDC A/S|TDC]] became the first Swedish ISP to start offering this feature to its customers.<ref>{{cite web|url=https://www.ripe.net/ripe/mail/archives/dns-wg/2007-February/001917.html|title=[dns-wg] Swedish ISP TCD Song Adopts DNSSEC|last=Eklund-Löwinder|first=Anne-Marie|date=12 February 2012|work=dns-wg mailing list|publisher=RIPE NCC|access-date=2 December 2012}}</ref>

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

{{cite web

|url=http://www.pir.org/get/registrars?order=field_dnssec_value&sort=desc

|title=.ORG Registrar List&nbsp;— 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 343 ⟶ 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: