~2025-40359-53: /* Preventing domain walking */

2025-12-13T00:22:38Z

Preventing domain walking

← Previous revision		Revision as of 00:22, 13 December 2025
Line 1:		Line 1:
	{{Short description\|Suite of IETF specifications}}		{{Short description\|Suite of IETF specifications}}
	{{Security protocol}}		{{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]].		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]]. As of 2025, DNSSEC deployment is spotty.

	==Overview==		==Overview==
Line 20:		Line 20:
	* Disagreement among implementers over who should own the [[top-level domain]] root keys		* Disagreement among implementers over who should own the [[top-level domain]] root keys
	* Overcoming the perceived complexity of DNSSEC and DNSSEC deployment		* Overcoming the perceived complexity of DNSSEC and DNSSEC deployment

			==Adoption==
			As of 2025, DNSSEC is only operational in 78 (48%) of [[country code top-level domain]]s.<ref>{{cite web\|url=https://maps.dnssec.gmu.edu/ \|access-date=September 25, 2025 \|title=DNSSEC Deployment Maps \|author=Center for Assurance Research and Engineering \|publisher=[[George Mason University]]}}</ref> ICANN made DNSSEC mandatory for new [[generic top-level domain]]s in 2014.<ref>[https://archief.dnssec.nl/nieuws/algemeen/dnssec-en-ipv6-vanaf-2014-verplicht-bij-icann/index.html DNSSEC en IPv6 vanaf 2014 verplicht bij ICANN]</ref> Not all lower-level domains use DNSSEC. Verisign reported about 5% adoption in [[.net]] second-level domains and about 4% in [[.com]].<ref>{{cite web \|url=https://www.verisign.com/en_US/company-information/verisign-labs/internet-security-tools/dnssec-scoreboard/index.xhtml \|access-date=September 25, 2025 \|title=
			DNSSEC Scoreboard \|publisher=[[Verisign]]}}</ref> 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").<ref>[https://www.sidn.nl/en/news-and-blogs/majority-of-dutch-domains-and-internet-users-have-dnssec-security Majority of Dutch domains and internet users have DNSSEC security]</ref> As of 2023, major domains like [[google.com]], [[amazon.com]], and [[microsoft.com]] were unsigned.<ref>{{cite web \|url=https://blog.apnic.net/2023/09/18/measuring-the-use-of-dnssec/ \|title=Measuring the use of DNSSEC \|author=[[Geoff Huston (scientist)\|Geoff Huston]] \|date=18 September 2023 \|publisher=[[APNIC]]}}</ref>

	==Operation==		==Operation==
Line 200:		Line 204:
	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]].		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> while native support ~~is currently awaiting someone to start working on it~~.<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>		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> up to Firefox 56, while native support was proposed but ultimately rejected.<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==		==History==
Line 219:		Line 223:
	The NSEC3 records (RFC 5155) were created as an alternative which hashes the name instead of listing them directly. Over time, advancements in hashing using GPUs and dedicated hardware meant that NSEC3 responses could be cheaply brute forced using offline dictionary attacks. [https://datatracker.ietf.org/doc/draft-vcelak-nsec5/ NSEC5] has been proposed to allow authoritative servers to sign NSEC responses without having to keep a private key that can be used to modify the zone. Thus stealing an NSEC5KEY would only result in the ability to more easily enumerate a zone.<ref>{{Cite web\|url=https://www.cs.bu.edu/~goldbe/papers/nsec5.html\|title=NSEC5: Provably Preventing DNSSEC Zone Enumeration}}</ref>		The NSEC3 records (RFC 5155) were created as an alternative which hashes the name instead of listing them directly. Over time, advancements in hashing using GPUs and dedicated hardware meant that NSEC3 responses could be cheaply brute forced using offline dictionary attacks. [https://datatracker.ietf.org/doc/draft-vcelak-nsec5/ NSEC5] has been proposed to allow authoritative servers to sign NSEC responses without having to keep a private key that can be used to modify the zone. Thus stealing an NSEC5KEY would only result in the ability to more easily enumerate a zone.<ref>{{Cite web\|url=https://www.cs.bu.edu/~goldbe/papers/nsec5.html\|title=NSEC5: Provably Preventing DNSSEC Zone Enumeration}}</ref>

	Due to the messy evolution of the protocol and a desire to preserve backwards compatibility, online DNSSEC signing servers return a "white lie" instead of authenticating a denial of existence directly. The technique outlined in RFC 4470 returns a NSEC record in which the pairs of domains lexically ~~surrounding~~ the requested domain. For example, request for <code>k.example.com</code> would thus result in an NSEC record proving that nothing exists between the (fictitious) domains <code>j.example.com</code> and <code>l.example.com</code>. This is also possible with NSEC3 records.<ref>{{Cite IETF \| rfc=7129\| title=Authenticated Denial of Existence in the DNS}}</ref>		Due to the messy evolution of the protocol and a desire to preserve backwards compatibility, online DNSSEC signing servers return a "white lie" instead of authenticating a denial of existence directly. The technique outlined in RFC 4470 returns a NSEC record in which the pairs of domains lexically surround the requested domain. For example, request for <code>k.example.com</code> would thus result in an NSEC record proving that nothing exists between the (fictitious) domains <code>j.example.com</code> and <code>l.example.com</code>. This is also possible with NSEC3 records.<ref>{{Cite IETF \| rfc=7129\| title=Authenticated Denial of Existence in the DNS}}</ref>

	CloudFlare pioneered a pair of alternative approaches, which manage to achieve the same result in one third of the response size.<ref name="cloudflare_black_lies">{{Cite web \| url=https://blog.cloudflare.com/black-lies/ \| title=Economical With The Truth: Making DNSSEC Answers Cheap\| date=2016-06-24}}</ref> The first is a variation on the "white lies" approach, called "black lies", which exploits common DNS client behavior to state the nonexistence more compactly.<ref>{{Cite IETF \| title=Compact DNSSEC Denial of Existence or Black Lies\| draft=draft-valsorda-dnsop-black-lies\| section=2\| sectionname=Black Lies}}</ref> The second approach instead chooses to prove that "the record exists but the requested record type does not", which they call "DNS shotgun".<ref>{{Cite web \| url=https://blog.cloudflare.com/dnssec-done-right/ \| title=DNSSEC Done Right\| date=2015-01-29}}</ref><ref name="cloudflare_black_lies"/>		CloudFlare pioneered a pair of alternative approaches, which manage to achieve the same result in one third of the response size.<ref name="cloudflare_black_lies">{{Cite web \| url=https://blog.cloudflare.com/black-lies/ \| title=Economical With The Truth: Making DNSSEC Answers Cheap\| date=2016-06-24}}</ref> The first is a variation on the "white lies" approach, called "black lies", which exploits common DNS client behavior to state the nonexistence more compactly.<ref>{{Cite IETF \| title=Compact DNSSEC Denial of Existence or Black Lies\| draft=draft-valsorda-dnsop-black-lies\| section=2\| sectionname=Black Lies}}</ref> The second approach instead chooses to prove that "the record exists but the requested record type does not", which they call "DNS shotgun".<ref>{{Cite web \| url=https://blog.cloudflare.com/dnssec-done-right/ \| title=DNSSEC Done Right\| date=2015-01-29}}</ref><ref name="cloudflare_black_lies"/>
Line 240:		Line 244:

	===Early deployments===		===Early deployments===
	Early adopters include [[Brazil]] ([[.br]]), [[Bulgaria]] ([[.bg]]), [[Czech Republic]] ([[.cz]]), [[Namibia]] ([[.na]])<ref>https://ccnso.icann.org/de/~~node~~/~~7603 {{Bare URL PDF~~\|date=~~March 2022~~}}</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>		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/sites/default/files/filefield_46433/gnso-25sep14-en.pdf \| access-date=2025-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>		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 276:		Line 280:
	On October 6, 2009, at the 59th [[RIPE]] Conference meeting, ICANN and VeriSign announced the planned deployment timeline for deploying DNSSEC within the root zone.<ref name="conf">{{cite web \| title = DNSSEC for the Root Zone \| url=http://www.ripe.net/ripe/meetings/ripe-59/presentations/abley-dnssec-root-zone.pdf}}</ref> At the meeting it was announced that it would be incrementally deployed to one root name server a month, starting on December 1, 2009, with the final root name server serving a DNSSEC signed zone on July 1, 2010, and the root zone will be signed with a RSA/SHA256 DNSKEY.<ref name="conf"/> During the incremental roll-out period the root zone will serve a ''Deliberately Unvalidatable Root Zone'' (DURZ) that uses dummy keys, with the final DNSKEY record not being distributed until July 1, 2010.<ref name="last-puzzle-pieces">{{Cite web \| last= Hutchinson \| first= James \| title= ICANN, Verisign place last puzzle pieces in DNSSEC saga \| work= NetworkWorld \| url= http://www.networkworld.com/news/2010/050610-icann-verisign-place-last-puzzle.html?hpg1=bn \| date= 6 May 2010 \| access-date= 17 May 2010 \| archive-date= 20 December 2013 \| archive-url= https://web.archive.org/web/20131220202008/http://www.networkworld.com/news/2010/050610-icann-verisign-place-last-puzzle.html?hpg1=bn \| url-status= dead }}</ref> This means the keys that were used to sign the zone use are deliberately unverifiable; the reason for this deployment was to monitor changes in traffic patterns caused by the larger responses to queries requesting DNSSEC resource records.		On October 6, 2009, at the 59th [[RIPE]] Conference meeting, ICANN and VeriSign announced the planned deployment timeline for deploying DNSSEC within the root zone.<ref name="conf">{{cite web \| title = DNSSEC for the Root Zone \| url=http://www.ripe.net/ripe/meetings/ripe-59/presentations/abley-dnssec-root-zone.pdf}}</ref> At the meeting it was announced that it would be incrementally deployed to one root name server a month, starting on December 1, 2009, with the final root name server serving a DNSSEC signed zone on July 1, 2010, and the root zone will be signed with a RSA/SHA256 DNSKEY.<ref name="conf"/> During the incremental roll-out period the root zone will serve a ''Deliberately Unvalidatable Root Zone'' (DURZ) that uses dummy keys, with the final DNSKEY record not being distributed until July 1, 2010.<ref name="last-puzzle-pieces">{{Cite web \| last= Hutchinson \| first= James \| title= ICANN, Verisign place last puzzle pieces in DNSSEC saga \| work= NetworkWorld \| url= http://www.networkworld.com/news/2010/050610-icann-verisign-place-last-puzzle.html?hpg1=bn \| date= 6 May 2010 \| access-date= 17 May 2010 \| archive-date= 20 December 2013 \| archive-url= https://web.archive.org/web/20131220202008/http://www.networkworld.com/news/2010/050610-icann-verisign-place-last-puzzle.html?hpg1=bn \| url-status= dead }}</ref> This means the keys that were used to sign the zone use are deliberately unverifiable; the reason for this deployment was to monitor changes in traffic patterns caused by the larger responses to queries requesting DNSSEC resource records.

	The [[.org]] top-level domain was signed with DNSSEC in June 2010, followed by [[.com]], [[.net]], and [[.edu]] later in 2010 and 2011.<ref>{{cite web\|url=http://www.thetechherald.com/article.php/201010/5366/DNSSEC-to-become-standard-on-ORG-domains-by-end-of-June\|title=DNSSEC to become standard on .ORG domains by end of June\|access-date=2010-03-24\|url-status=~~dead~~\|archive-url=https://web.archive.org/web/20100315143451/http://www.thetechherald.com/article.php/201010/5366/DNSSEC-to-become-standard-on-ORG-domains-by-end-of-June\|archive-date=2010-03-15}}</ref><ref>[https://web.archive.org/web/20110404225604/http://www.theinquirer.net/inquirer/news/2039648/verisign-deploys-dnssec-com-tld The Inquirer: Verisign deploys DNSSEC on .com TLD]</ref> [[Country code top-level domain]]s were able to deposit keys starting in May 2010.<ref name="heise">[http://www.h-online.com/security/news/item/More-security-for-root-DNS-servers-962569.html More security for root DNS servers] Heise Online, 24 March 2010</ref> {{As of\|2011\|11}} more than 25% of top-level domains are signed with DNSSEC.<ref>[http://www.circleid.com/posts/20111130_dnssec_update_from_icann_42_in_dakar/ CircleID: DNSSEC Update from ICANN 42 in Dakar]</ref>		The [[.org]] top-level domain was signed with DNSSEC in June 2010, followed by [[.com]], [[.net]], and [[.edu]] later in 2010 and 2011.<ref>{{cite web\|url=http://www.thetechherald.com/article.php/201010/5366/DNSSEC-to-become-standard-on-ORG-domains-by-end-of-June\|title=DNSSEC to become standard on .ORG domains by end of June\|access-date=2010-03-24\|url-status=usurped\|archive-url=https://web.archive.org/web/20100315143451/http://www.thetechherald.com/article.php/201010/5366/DNSSEC-to-become-standard-on-ORG-domains-by-end-of-June\|archive-date=2010-03-15}}</ref><ref>[https://web.archive.org/web/20110404225604/http://www.theinquirer.net/inquirer/news/2039648/verisign-deploys-dnssec-com-tld The Inquirer: Verisign deploys DNSSEC on .com TLD]</ref> [[Country code top-level domain]]s were able to deposit keys starting in May 2010.<ref name="heise">[http://www.h-online.com/security/news/item/More-security-for-root-DNS-servers-962569.html More security for root DNS servers] Heise Online, 24 March 2010</ref> {{As of\|2011\|11}} more than 25% of top-level domains are signed with DNSSEC.<ref>[http://www.circleid.com/posts/20111130_dnssec_update_from_icann_42_in_dakar/ CircleID: DNSSEC Update from ICANN 42 in Dakar]</ref>

	====Implementation====		====Implementation====
Line 318:		Line 322:

	====DNSSEC support====		====DNSSEC support====
	{{See also\|~~Public_recursive_name_server~~#~~Notable_public_DNS_service_operators~~}}		{{See also\|Public recursive name server#Notable public DNS service operators}}
	Google's [[Google Public DNS\|public recursive DNS]] server enabled DNSSEC validation on May 6, 2013.<ref>[https://security.googleblog.com/2013/03/google-public-dns-now-supports-dnssec.html Google Public DNS Now Supports DNSSEC Validation] Google Code Blog, 1 June 2013</ref>		Google's [[Google Public DNS\|public recursive DNS]] server enabled DNSSEC validation on May 6, 2013.<ref>[https://security.googleblog.com/2013/03/google-public-dns-now-supports-dnssec.html Google Public DNS Now Supports DNSSEC Validation] Google Code Blog, 1 June 2013</ref>

Domain Name System Security Extensions - Revision history

~2025-40359-53: /* Preventing domain walking */

imported>Steel1943: /* Overview */ MOS:REFSPACE (remove space between reference tags), replaced: /ref>
2025-03-09T08:19:43Z

Overview: MOS:REFSPACE (remove space between reference tags), replaced: /ref> <ref → /ref><ref
Show changes

Domain Name System Security Extensions - Revision history

~2025-40359-53: /* Preventing domain walking */

imported>Steel1943: /* Overview */ MOS:REFSPACE (remove space between reference tags), replaced: /ref> 2025-03-09T08:19:43Z Overview: MOS:REFSPACE (remove space between reference tags), replaced: /ref> <ref → /ref><ref Show changes

imported>Steel1943: /* Overview */ MOS:REFSPACE (remove space between reference tags), replaced: /ref>
2025-03-09T08:19:43Z

Overview: MOS:REFSPACE (remove space between reference tags), replaced: /ref> <ref → /ref><ref
Show changes