Domain Name System Security Extensions: Difference between revisions

Revision as of 01:36, 26 July 2025

Latest revision as of 18:52, 8 August 2025

(2 intermediate revisions by 2 users not shown)

Line 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 211:

In January 2024, a "KeyTrap" denial-of-service attack was announced for all specification-respecting DNSSEC resolvers. The DNSSEC specification (RFC4033-4035) specifies that a resolver, when receiving a signed packet from the upstream, should try ''all'' keys with the correct "tag" on ''all'' signatures until one of the combinations successfully verifies. By putting many keys with the same "tag" and many signatures corresponding to that "tag" in a packet, the researchers can slow down a resolver by a factor of 2 million. In response, resolvers began to place limits on the amount of verification errors, key tag collisions, and hash calculations.<ref>{{cite web |title=The KeyTrap Denial-of-Service Algorithmic Complexity Attacks on DNS Version: January 2024 |author1=Elias Heftrig|author2= Haya Schulmann |author3= Niklas Vogel |author4= Michael Waidne |url=https://www.athene-center.de/fileadmin/content/PDF/Keytrap_2401.pdf |website=ATHENE}} ([https://www.athene-center.de/en/keytrap press release])</ref>

==Authenticating<ref>{{Unprintworthy block}}</ref> NXDOMAIN responses and NSEC==

Cryptographically proving the absence of a ___domain requires signing the response to every query for a non-existent ___domain. This is not a problem for online signing servers, which keep their keys available online. However, DNSSEC was designed around using offline computers to sign records so that zone-signing-keys could be kept in cold storage. This represents a problem when trying to authenticate responses to queries for non-existent domains since it is impossible to pre-generate a response to every possible hostname query.

Line 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>