Content deleted Content added
Paulehoffman (talk | contribs) Started converting more RFCs to IETF citations |
→Early deployments: bare url corrected |
||
| (44 intermediate revisions by 29 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/
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
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:
Line 37:
====Algorithms====
DNSSEC was designed to be extensible so that as attacks are discovered against existing algorithms, new ones can be introduced in a [[backward-compatible]] fashion as described in {{IETF RFC|8624}}. The following table defines, as of June 2019, the security algorithms that are or were most often used:<ref>{{cite web
| url = https://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml
| title = Domain Name System Security (DNSSEC) Algorithm Numbers | date = 2010-07-12 | access-date = 2010-07-17
Line 49:
! Source
! DNSSEC Signing
! DNSSEC Validation
|-
| 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}}
|-
| 6 || DSA-NSEC3-SHA1 || || {{no|Must Not Implement}} || {{no|Must Not Implement}}
|-
| 7 || RSASHA1-NSEC3-SHA1 || {{IETF RFC | 5155}}|| {{no2|Not Recommended}} || {{yes|Required}}
|-
| 8 || RSA/[[SHA-2|SHA-256]] || rowspan="2" | {{IETF RFC| 5702}}|| {{yes|Required}} || {{yes|Required}}
|-
| 10 || RSA/[[SHA-2|SHA-512]] || {{no2|Not Recommended}} || {{yes|Required}}
|-
| 12 || [[GOST]] [[GOST (hash function)|R 34.10-2001]] || {{IETF RFC |5933}}|| {{no|Must Not Implement}} || {{Okay|Optional}}
|-
| 13 || [[Elliptic Curve DSA|ECDSA]] P-256/[[SHA-2|SHA-256]] || rowspan="2" | {{ IETF RFC | 6605}}|| {{yes|Required}} || {{yes|Required}}
|-
| 14 || ECDSA P-384/[[SHA-2|SHA-384]] || {{Okay|Optional}} || {{partial|Recommended}}
|-
| 15 || [[Ed25519]] || rowspan="2" | {{IETF RFC |8080 }}|| {{partial|Recommended}} || {{partial|Recommended}}
|-
| 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 93 ⟶ 94:
! Source
! DNSSEC Delegation
! DNSSEC Validation
|-
|
|-
| 2 || [[SHA-256]] || {{ IETF RFC |4509 }}|| {{yes|Required}} || {{yes|Required}}
|-
|
|-
|
|-
|5
|[[GOST]] [[Streebog|R 34.11-2012]]
| {{IETF RFC | 9563}}
| {{okay|Optional}}
| {{okay|Optional}}
|-
|6
▲| 4 || [[SHA-384]] || RFC 6605|| {{okay|Optional}} || {{partial|Recommended}}
| SM3
| {{IETF RFC | 9558}}
| {{okay|Optional}}
| {{okay|Optional}}
|}
Line 121 ⟶ 123:
Using the [[chain of trust]] model, a Delegation Signer (DS) record in a parent ___domain ([[DNS zone]]) can be used to verify a DNSKEY record in a [[subdomain]], which can then contain other DS records to verify further subdomains. Say that a recursive resolver such as an ISP name server wants to get the IP addresses ([[A record]] and/or [[AAAA record]]s) of the ___domain "www.[[example.com]]".
# The process starts when a security-aware resolver sets the "DO" ("DNSSEC OK"
# When the resolver receives an answer via the normal DNS lookup process, it then checks to make sure that the answer is correct. Ideally, the security-aware resolver would start with verifying the DS and DNSKEY records at the [[DNS root]]. Then it would use the DS records for the "com" [[top-level ___domain]] found at the root to verify the DNSKEY records in the "com" zone. From there, it would see if there is a DS record for the "example.com" subdomain in the "com" zone, and if there were, it would then use the DS record to verify a DNSKEY record found in the "example.com" zone. Finally, it would verify the RRSIG record found in the answer for the A records for "www.example.com".
Line 130 ⟶ 132:
Next, it may be that there is not a ___domain name named "www.example.com", in which case instead of returning a RRSIG record in the answer, there will be either an NSEC record or an NSEC3 record. These are "next secure" records that allow the resolver to prove that a ___domain name does not exist. The NSEC/NSEC3 records have RRSIG records, which can be verified as above.
Finally, it may be that the "example.com" zone implements DNSSEC, but either the "com" zone or the root zone do not, creating an "island of security" which needs to be validated in some other way. {{as of|2010|7|15}}, deployment of DNSSEC to root is completed.<ref>{{Cite web | url=
====Stub resolvers====
Line 190 ⟶ 192:
When a new KSK is created, the DS record must be transferred to the parent zone and published there. The DS records use a [[message digest]] of the KSK instead of the complete key in order to keep the size of the records small. This is helpful for zones such as the [[.com]] ___domain, which are very large. The procedure to update DS keys in the parent zone is also simpler than earlier DNSSEC versions that required DNSKEY records to be in the parent zone.
A closely related principle is that of '''Algorithm rollover''', this involves migrating a zone from one signing Algorithm to another. A good example of this would be migrating from Algorithm 8 (RSA/SHA-256) to Algorithm 13 (ECDSA/SHA-256). Several ccTLD's have already migrated including [[.at]], [[.br]], [[.cz]], [[.ch]], [[.fr]], [[.ie]], [[.nl]]<ref>{{cite web |last1=Ubbink |first1=Stefan |title=New DNSSEC algorithm for .nl |url=https://www.sidn.nl/en/news-and-blogs/new-dnssec-algorithm-for-nl |website=www.sidn.nl |access-date=29 January 2024}}</ref> and [[.ph]]. [[Verisign]] migrated .com, .net and .edu to Algorithm 13 in late 2023.<ref>{{cite web |last1=Wessels |first1=Duane |title=Verisign Will Help Strengthen Security with DNSSEC Algorithm Update |url=https://blog.verisign.com/security/dnssec-algorithm-update/ |website=Verisign Blog |access-date=29 January 2024 |date=10 August 2023}}</ref><ref>{{cite web |last1=Wessels |first1=Duane |title=Transitioning Verisign's TLDs to Elliptic Curve DNSSEC |url=https://indico.dns-oarc.net/event/47/contributions/1012/ |website=DNS-OARC |access-date=29 January 2024}}</ref> The migration of the root ___domain from Algorithm 8 to Algorithm 13 is currently in planning as of early 2024.<ref>{{cite web |title=Root Zone KSK Algorithm Rollover - ICANN |url=https://www.icann.org/resources/pages/ksk-algorithm-rollover-en |website=www.icann.org |access-date=29 January 2024}}</ref>
===DANE Working Group===
Line 196 ⟶ 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 203 ⟶ 207:
Unfortunately, the IETF RFC 2535 specification had very significant problems scaling up to the full Internet; by 2001 it became clear that this specification was unusable for large networks. In normal operation DNS servers often get out of sync with their parents. This isn't usually a problem, but when DNSSEC is enabled, this out-of-sync data could have the effect of a serious self-created denial of service. The original DNSSEC required a complex six-message protocol and a lot of data transfers to perform key changes for a child (DNS child zones had to send all of their data up to the parent, have the parent sign each record, and then send those signatures back to the child for the child to store in a SIG record). Also, public key changes could have absurd effects; for example, if the ".com" zone changed its public key, it would have to send 22 million records (because it would need to update all of the signatures in all of its children). Thus, DNSSEC as defined in RFC 2535 could not scale up to the Internet.
The IETF fundamentally modified DNSSEC, which is called ''DNSSEC-bis'' when necessary to distinguish it from the original DNSSEC approach of RFC 2535. This new version uses "delegation signer (DS) resource records" to provide an additional level of indirection at delegation points between a parent and child zone. In the new approach, when a child's master public key changes, instead of having six messages for every record in the child, there is one simple message: the child sends the new public key to its parent (signed, of course). Parents simply store one master public key for each child; this is much more practical. This means that a little data is pushed to the parent, instead of massive amounts of data being exchanged between the parent and children. This does mean that clients have to do a little more work when verifying keys. More specifically, verifying a DNS zone's KEY RRset requires two signature verification operations instead of the one required by RFC 2535 (there is no impact on the number of signatures verified for other types of RRsets). Most view this as a small price to pay, since it makes DNSSEC deployment more practical. The new version is published in RFC4033-4035.
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 NXDOMAIN responses and NSEC==
Line 234 ⟶ 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 245 ⟶ 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 255 ⟶ 263:
===Deployment at the DNS root===
DNSSEC was first deployed at the root level on July 15, 2010.<ref name="dnssec-status-live">{{cite web|title=
Political issues surrounding signing the root have been a continuous concern, primarily about some central issues:
Line 262 ⟶ 270:
====Planning====
In September 2008, ICANN and VeriSign each published implementation proposals<ref>{{cite news|author=Singel, Ryan|title=Feds Start Moving on Net Security Hole|url=http://blog.wired.com/27bstroke6/2008/10/feds-take-step.html|date=October 8, 2006|work=Wired News|publisher=CondéNet|access-date=2008-10-09}}</ref> and in October, the [[National Telecommunications and Information Administration]] (NTIA) asked the public for comments.<ref>{{cite press release|title=Press Release: NTIA Seeks Public Comments for the Deployment of Security Technology Within the Internet Domain Name System|url=http://www.ntia.doc.gov/press/2008/DNSSEC_081009.html|date=October 9, 2008|publisher=National Telecommunications and Information Administration, U.S. Department of Commerce|access-date=2008-10-09|archive-date=2008-10-13|archive-url=https://web.archive.org/web/20081013070057/http://www.ntia.doc.gov/press/2008/DNSSEC_081009.html|url-status=dead}}</ref> It is unclear if the comments received affected the design of the final deployment plan.
On June 3, 2009, the [[National Institute of Standards and Technology]] (NIST) announced plans to sign the root by the end of 2009, in conjunction with ICANN, [[VeriSign]] and the NTIA.<ref name="NISTpr609">{{cite press release | url= https://www.nist.gov/public_affairs/releases/dnssec_060309.html | title= Commerce Department to Work with ICANN and VeriSign to Enhance the Security and Stability of the Internet's Domain Name and Addressing System | publisher= National Institute of Standards and Technology | date= 3 June 2009 | access-date= 13 July 2017 | archive-date= 29 June 2011 | archive-url= https://web.archive.org/web/20110629074556/http://www.nist.gov/public_affairs/releases/dnssec_060309.html | url-status= dead }}</ref>
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
====Implementation====
On January 25, 2010, the L (ell) root server began serving a ''Deliberately Unvalidatable Root Zone'' (DURZ). The zone uses signatures of a [[SHA-2]] (SHA-256) hash created using the [[RSA (algorithm)|RSA]] algorithm, as defined in
===Deployment at the TLD level===
Line 285 ⟶ 293:
ISC decommissioned its DLV registry in 2017.<ref>{{Cite web|title=DLV Replaced With Signed Empty Zone - Internet Systems Consortium|url=https://www.isc.org/blogs/dlv-replaced-with-signed-empty-zone/|access-date=2020-06-05|website=isc.org|date=30 September 2017}}</ref> DLV support was deprecated in BIND 9.12 and completely removed from BIND 9.16.<ref>{{Cite web|title=BIND 9.16.0, Stable Branch for 2020 and Beyond - Internet Systems Consortium|url=https://www.isc.org/blogs/bind9.16.0_released/|access-date=2020-06-05|website=isc.org|date=20 February 2020}}</ref> Unbound version 1.5.4 (July 2015) marked DLV as decommissioned in the example configuration and manual page.<ref>{{Cite web|title=Unbound 1.5.4 Changes|url=https://nlnetlabs.nl/projects/unbound/download/#unbound-1-5-4|access-date=2020-06-05|website=NLnet Labs|language=en}}</ref> Knot Resolver and PowerDNS Recursor never implemented DLV.
In March 2020, the [[IETF]] published {{IETF RFC | 8749}}, retiring DLV as a standard and moving RFC 4432 and RFC 5074 to "Historic" status.<ref>{{cite IETF |title=Moving DNSSEC Lookaside Validation (DLV) to Historic Status |rfc=879 |last1=Mekking |first1=W. |author-link1=W. (Matthijs) Mekking |last2=Mahoney |first2=D. |author-link2=Dan Mahoney (computer scientist) |date= March 2020 |publisher=[[Internet Engineering Task Force|IETF]] |access-date= 3 June 2020|doi=10.17487/RFC8749 }}</ref>
===DNSSEC deployment initiative by the U.S. federal government===
Line 310 ⟶ 318:
====DNSSEC support====
{{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>
Line 315 ⟶ 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 ==
[[Geoff Huston (scientist)|Geoff Hutson]] has argued that DNSSEC deployment should be given up.<ref>{{Cite web |last=Huston |first=Geoff |date=2024-05-28 |title=Calling time on DNSSEC? |url=https://blog.apnic.net/2024/05/28/calling-time-on-dnssec/ |access-date=2024-05-28 |website=APNIC Blog |language=en-US}}</ref>
==IETF publications==
Line 333 ⟶ 349:
* {{IETF RFC|5155}} DNSSEC Hashed Authenticated Denial of Existence
* {{IETF RFC|5702}} Use of SHA-2 Algorithms with RSA in DNSKEY and RRSIG Resource Records for DNSSEC
* {{IETF RFC|6014}} Cryptographic Algorithm Identifier Allocation for DNSSEC
* {{IETF RFC|6605}} Elliptic Curve Digital Signature Algorithm (DSA) for DNSSEC
* {{IETF RFC|6725}} DNS Security (DNSSEC) DNSKEY Algorithm IANA Registry Updates
* {{IETF RFC|6781}} DNSSEC Operational Practices, Version 2
* {{IETF RFC|6840}} Clarifications and Implementation Notes for DNS Security (DNSSEC)
* {{IETF RFC|6975}} Signaling Cryptographic Algorithm Understanding in DNS Security Extensions (DNSSEC)
* {{IETF RFC|7129}} Authenticated Denial of Existence in the DNS
* {{IETF RFC|7344}} Automating DNSSEC Delegation Trust Maintenance
* {{IETF RFC|7583}} DNSSEC Key Rollover Timing Considerations
* {{IETF RFC|8078}} Managing DS Records from the Parent via CDS/CDNSKEY
* {{IETF RFC|8080}} Edwards-Curve Digital Security Algorithm (EdDSA) for DNSSEC
* {{IETF RFC|8198}} Aggressive Use of DNSSEC-Validated Cache
* {{IETF RFC|8624}} Algorithm Implementation Requirements and Usage Guidance for DNSSEC
* {{IETF RFC|8749}} Moving DNSSEC Lookaside Validation (DLV) to Historic Status
* {{IETF RFC|9077}} NSEC and NSEC3: TTLs and Aggressive Use
* {{IETF RFC|9157}} Revised IANA Considerations for DNSSEC
* {{IETF RFC|9276}} Guidance for NSEC3 Parameter Settings
* {{IETF RFC|9364}} ([[Request_for_Comments#Best_Current_Practice|BCP]] 237) DNS Security Extensions
==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:
Line 373 ⟶ 396:
==External links==
* [https://www.dnssec.net/ DNSSEC]
* [https://web.archive.org/web/20031008105543/http://www.ietf.org/html.charters/dnsext-charter.html DNSEXT] DNS Extensions [[IETF Working Group]]
* [https://web.archive.org/web/20190429202558/http://dnssec-tools.org/ DNSSEC-Tools Project]
{{Authority control}}
[[Category:Internet Standards]]
| |||