summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc9364.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc9364.txt')
-rw-r--r--doc/rfc/rfc9364.txt507
1 files changed, 507 insertions, 0 deletions
diff --git a/doc/rfc/rfc9364.txt b/doc/rfc/rfc9364.txt
new file mode 100644
index 0000000..6c7746d
--- /dev/null
+++ b/doc/rfc/rfc9364.txt
@@ -0,0 +1,507 @@
+
+
+
+
+Internet Engineering Task Force (IETF) P. Hoffman
+Request for Comments: 9364 ICANN
+BCP: 237 February 2023
+Category: Best Current Practice
+ISSN: 2070-1721
+
+
+ DNS Security Extensions (DNSSEC)
+
+Abstract
+
+ This document describes the DNS Security Extensions (commonly called
+ "DNSSEC") that are specified in RFCs 4033, 4034, and 4035, as well as
+ a handful of others. One purpose is to introduce all of the RFCs in
+ one place so that the reader can understand the many aspects of
+ DNSSEC. This document does not update any of those RFCs. A second
+ purpose is to state that using DNSSEC for origin authentication of
+ DNS data is the best current practice. A third purpose is to provide
+ a single reference for other documents that want to refer to DNSSEC.
+
+Status of This Memo
+
+ This memo documents an Internet Best Current Practice.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Further information on
+ BCPs is available in Section 2 of RFC 7841.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ https://www.rfc-editor.org/info/rfc9364.
+
+Copyright Notice
+
+ Copyright (c) 2023 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (https://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Revised BSD License text as described in Section 4.e of the
+ Trust Legal Provisions and are provided without warranty as described
+ in the Revised BSD License.
+
+Table of Contents
+
+ 1. Introduction
+ 1.1. DNSSEC as a Best Current Practice
+ 1.2. Implementing DNSSEC
+ 2. DNSSEC Core Documents
+ 2.1. Addition to the DNSSEC Core
+ 3. Additional Cryptographic Algorithms and DNSSEC
+ 4. Extensions to DNSSEC
+ 5. Additional Documents of Interest
+ 6. IANA Considerations
+ 7. Security Considerations
+ 8. References
+ 8.1. Normative References
+ 8.2. Informative References
+ Acknowledgements
+ Author's Address
+
+1. Introduction
+
+ The core specification for what we know as DNSSEC (the combination of
+ [RFC4033], [RFC4034], and [RFC4035]) describes a set of protocols
+ that provide origin authentication of DNS data. [RFC6840] updates
+ and extends those core RFCs but does not fundamentally change the way
+ that DNSSEC works.
+
+ This document lists RFCs that should be considered by someone
+ creating an implementation of, or someone deploying, DNSSEC as it is
+ currently standardized. Although an effort was made to be thorough,
+ the reader should not assume this list is comprehensive. It uses
+ terminology from those documents without defining that terminology.
+ It also points to the relevant IANA registry groups that relate to
+ DNSSEC. It does not, however, point to standards that rely on zones
+ needing to be signed by DNSSEC, such as DNS-Based Authentication of
+ Named Entities (DANE) [RFC6698].
+
+1.1. DNSSEC as a Best Current Practice
+
+ Using the DNSSEC set of protocols is the best current practice for
+ adding origin authentication of DNS data. To date, no Standards
+ Track RFCs offer any other method for such origin authentication of
+ data in the DNS.
+
+ More than 15 years after the DNSSEC specification was published, it
+ is still not widely deployed. Recent estimates are that fewer than
+ 10% of the domain names used for websites are signed, and only around
+ a third of queries to recursive resolvers are validated. However,
+ this low level of deployment does not affect whether using DNSSEC is
+ a best current practice; it just indicates that the value of
+ deploying DNSSEC is often considered lower than the cost.
+ Nonetheless, the significant deployment of DNSSEC beneath some top-
+ level domains (TLDs) and the near-universal deployment of DNSSEC for
+ the TLDs in the DNS root zone demonstrate that DNSSEC is applicable
+ for implementation by both ordinary and highly sophisticated domain
+ owners.
+
+1.2. Implementing DNSSEC
+
+ Developers of validating resolvers and authoritative servers, as well
+ as operators of validating resolvers and authoritative servers, need
+ to know the parts of the DNSSEC protocol that would affect them.
+ They should read the DNSSEC core documents and probably at least be
+ familiar with the extensions. Developers will probably need to be
+ very familiar with the algorithm documents as well.
+
+ As a side note, some of the DNSSEC-related RFCs have significant
+ errata, so reading the RFCs should also include looking for the
+ related errata.
+
+2. DNSSEC Core Documents
+
+ What we refer to as "DNSSEC" is the third iteration of the DNSSEC
+ specification; [RFC2065] was the first, and [RFC2535] was the second.
+ Earlier iterations have not been deployed on a significant scale.
+ Throughout this document, "DNSSEC" means the protocol initially
+ defined in [RFC4033], [RFC4034], and [RFC4035].
+
+ The three initial core documents generally cover different topics:
+
+ * [RFC4033] is an overview of DNSSEC, including how it might change
+ the resolution of DNS queries.
+
+ * [RFC4034] specifies the DNS resource records used in DNSSEC. It
+ obsoletes many RFCs about earlier versions of DNSSEC.
+
+ * [RFC4035] covers the modifications to the DNS protocol incurred by
+ DNSSEC. These include signing zones, serving signed zones,
+ resolving in light of DNSSEC, and authenticating DNSSEC-signed
+ data.
+
+ At the time this set of core documents was published, someone could
+ create a DNSSEC implementation of signing software, of a DNSSEC-aware
+ authoritative server, and/or of a DNSSEC-aware recursive resolver
+ from the three core documents, plus a few older RFCs specifying the
+ cryptography used. Those two older documents are the following:
+
+ * [RFC2536] defines how to use the DSA signature algorithm (although
+ it refers to other documents for the details). DSA was thinly
+ implemented and can safely be ignored by DNSSEC implementations.
+
+ * [RFC3110] defines how to use the RSA signature algorithm (although
+ refers to other documents for the details). RSA is still among
+ the most popular signing algorithms for DNSSEC.
+
+ It is important to note that later RFCs update the core documents.
+ As just one example, [RFC9077] changes how TTL values are calculated
+ in DNSSEC processing.
+
+2.1. Addition to the DNSSEC Core
+
+ As with any major protocol, developers and operators discovered
+ issues with the original core documents over the years. [RFC6840] is
+ an omnibus update to the original core documents and thus itself has
+ become a core document. In addition to covering new requirements
+ from new DNSSEC RFCs, it describes many important security and
+ interoperability issues that arose during the deployment of the
+ initial specifications, particularly after the DNS root was signed in
+ 2010. It also lists some errors in the examples of the core
+ specifications.
+
+ [RFC6840] brings a few additions into the core of DNSSEC. It makes
+ NSEC3 [RFC5155] as much a part of DNSSEC as NSEC is. It also makes
+ the SHA-256 and SHA-512 hash functions defined in [RFC4509] and
+ [RFC5702] part of the core.
+
+3. Additional Cryptographic Algorithms and DNSSEC
+
+ Current cryptographic algorithms typically weaken over time as
+ computing power improves and new cryptoanalysis emerges. Two new
+ signing algorithms have been adopted by the DNSSEC community:
+ Elliptic Curve Digital Signature Algorithm (ECDSA) [RFC6605] and
+ Edwards-curve Digital Signature Algorithm (EdDSA) [RFC8080]. ECDSA
+ and EdDSA have become very popular signing algorithms in recent
+ years. The GOST signing algorithm [GOST-SIGN] was also adopted but
+ has seen very limited use, likely because it is a national algorithm
+ specific to a very small number of countries.
+
+ Implementation developers who want to know which algorithms to
+ implement in DNSSEC software should refer to [RFC8624]. Note that
+ this specification is only about what algorithms should and should
+ not be included in implementations, i.e., it is not advice about
+ which algorithms zone operators should or should not use for signing,
+ nor which algorithms recursive resolver operators should or should
+ not use for validation.
+
+4. Extensions to DNSSEC
+
+ The DNSSEC community has extended the DNSSEC core and the
+ cryptographic algorithms, both in terms of describing good
+ operational practices and in new protocols. Some of the RFCs that
+ describe these extensions include the following:
+
+ * [RFC5011] describes a method to help resolvers update their DNSSEC
+ trust anchors in an automated fashion. This method was used in
+ 2018 to update the DNS root trust anchor.
+
+ * [RFC6781] is a compendium of operational practices that may not be
+ obvious from reading just the core specifications.
+
+ * [RFC7344] describes using the CDS and CDNSKEY resource records to
+ help automate the maintenance of DS records in the parents of
+ signed zones.
+
+ * [RFC8078] extends [RFC7344] by showing how to do initial setup of
+ trusted relationships between signed parent and child zones.
+
+ * [RFC8198] describes how a validating resolver can emit fewer
+ queries in signed zones that use NSEC and NSEC3 for negative
+ caching.
+
+ * [RFC9077] updates [RFC8198] with respect to the TTL fields in
+ signed records.
+
+5. Additional Documents of Interest
+
+ The documents listed above constitute the core of DNSSEC, the
+ additional cryptographic algorithms, and the major extensions to
+ DNSSEC. This section lists some additional documents that someone
+ interested in implementing or operating DNSSEC might find of value:
+
+ * [RFC4470] "describes how to construct DNSSEC NSEC resource records
+ that cover a smaller range of names than called for by [RFC4034].
+ By generating and signing these records on demand, authoritative
+ name servers can effectively stop the disclosure of zone contents
+ otherwise made possible by walking the chain of NSEC records in a
+ signed zone".
+
+ * [RFC6975] "specifies a way for validating end-system resolvers to
+ signal to a server which digital signature and hash algorithms
+ they support".
+
+ * [RFC7129] "provides additional background commentary and some
+ context for the NSEC and NSEC3 mechanisms used by DNSSEC to
+ provide authenticated denial-of-existence responses". This
+ background is particularly important for understanding NSEC and
+ NSEC3 usage.
+
+ * [RFC7583] "describes the issues surrounding the timing of events
+ in the rolling of a key in a DNSSEC-secured zone".
+
+ * [RFC7646] "defines Negative Trust Anchors (NTAs), which can be
+ used to mitigate DNSSEC validation failures by disabling DNSSEC
+ validation at specified domains".
+
+ * [RFC7958] "describes the format and publication mechanisms IANA
+ has used to distribute the DNSSEC trust anchors".
+
+ * [RFC8027] "describes problems that a Validating DNS resolver,
+ stub-resolver, or application might run into within a non-
+ compliant infrastructure".
+
+ * [RFC8145] "specifies two different ways for validating resolvers
+ to signal to a server which keys are referenced in their chain of
+ trust".
+
+ * [RFC8499] contains lists of terminology used when talking about
+ DNS; Sections 10 and 11 cover DNSSEC.
+
+ * [RFC8509] "specifies a mechanism that will allow an end user and
+ third parties to determine the trusted key state for the root key
+ of the resolvers that handle that user's DNS queries".
+
+ * [RFC8901] "presents deployment models that accommodate this
+ scenario [when each DNS provider independently signs zone data
+ with their own keys] and describes these key-management
+ requirements".
+
+ * [RFC9276] "provides guidance on setting NSEC3 parameters based on
+ recent operational deployment experience".
+
+ There will certainly be other RFCs related to DNSSEC that are
+ published after this one.
+
+6. IANA Considerations
+
+ IANA already has three registry groups that relate to DNSSEC:
+
+ * DNSSEC algorithm numbers (https://www.iana.org/assignments/dns-
+ sec-alg-numbers)
+
+ * DNSSEC NSEC3 parameters (https://www.iana.org/assignments/dnssec-
+ nsec3-parameters)
+
+ * DNSSEC DS RRtype digest algorithms
+ (https://www.iana.org/assignments/ds-rr-types)
+
+ The rules for the DNSSEC algorithm registry were set in the core RFCs
+ and updated by [RFC6014], [RFC6725], and [RFC9157].
+
+ This document does not update or create any registry groups or
+ registries.
+
+7. Security Considerations
+
+ All of the security considerations from all of the RFCs referenced in
+ this document apply here.
+
+8. References
+
+8.1. Normative References
+
+ [RFC3110] Eastlake 3rd, D., "RSA/SHA-1 SIGs and RSA KEYs in the
+ Domain Name System (DNS)", RFC 3110, DOI 10.17487/RFC3110,
+ May 2001, <https://www.rfc-editor.org/info/rfc3110>.
+
+ [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
+ Rose, "DNS Security Introduction and Requirements",
+ RFC 4033, DOI 10.17487/RFC4033, March 2005,
+ <https://www.rfc-editor.org/info/rfc4033>.
+
+ [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
+ Rose, "Resource Records for the DNS Security Extensions",
+ RFC 4034, DOI 10.17487/RFC4034, March 2005,
+ <https://www.rfc-editor.org/info/rfc4034>.
+
+ [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
+ Rose, "Protocol Modifications for the DNS Security
+ Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005,
+ <https://www.rfc-editor.org/info/rfc4035>.
+
+ [RFC4509] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer
+ (DS) Resource Records (RRs)", RFC 4509,
+ DOI 10.17487/RFC4509, May 2006,
+ <https://www.rfc-editor.org/info/rfc4509>.
+
+ [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
+ Security (DNSSEC) Hashed Authenticated Denial of
+ Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008,
+ <https://www.rfc-editor.org/info/rfc5155>.
+
+ [RFC5702] Jansen, J., "Use of SHA-2 Algorithms with RSA in DNSKEY
+ and RRSIG Resource Records for DNSSEC", RFC 5702,
+ DOI 10.17487/RFC5702, October 2009,
+ <https://www.rfc-editor.org/info/rfc5702>.
+
+ [RFC6840] Weiler, S., Ed. and D. Blacka, Ed., "Clarifications and
+ Implementation Notes for DNS Security (DNSSEC)", RFC 6840,
+ DOI 10.17487/RFC6840, February 2013,
+ <https://www.rfc-editor.org/info/rfc6840>.
+
+8.2. Informative References
+
+ [GOST-SIGN]
+ Belyavsky, D., Dolmatov, V., Ed., and B. Makarenko, Ed.,
+ "Use of GOST 2012 Signature Algorithms in DNSKEY and RRSIG
+ Resource Records for DNSSEC", Work in Progress, Internet-
+ Draft, draft-ietf-dnsop-rfc5933-bis-13, 30 November 2022,
+ <https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-
+ rfc5933-bis-13>.
+
+ [RFC2065] Eastlake 3rd, D. and C. Kaufman, "Domain Name System
+ Security Extensions", RFC 2065, DOI 10.17487/RFC2065,
+ January 1997, <https://www.rfc-editor.org/info/rfc2065>.
+
+ [RFC2535] Eastlake 3rd, D., "Domain Name System Security
+ Extensions", RFC 2535, DOI 10.17487/RFC2535, March 1999,
+ <https://www.rfc-editor.org/info/rfc2535>.
+
+ [RFC2536] Eastlake 3rd, D., "DSA KEYs and SIGs in the Domain Name
+ System (DNS)", RFC 2536, DOI 10.17487/RFC2536, March 1999,
+ <https://www.rfc-editor.org/info/rfc2536>.
+
+ [RFC4470] Weiler, S. and J. Ihren, "Minimally Covering NSEC Records
+ and DNSSEC On-line Signing", RFC 4470,
+ DOI 10.17487/RFC4470, April 2006,
+ <https://www.rfc-editor.org/info/rfc4470>.
+
+ [RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC)
+ Trust Anchors", STD 74, RFC 5011, DOI 10.17487/RFC5011,
+ September 2007, <https://www.rfc-editor.org/info/rfc5011>.
+
+ [RFC6014] Hoffman, P., "Cryptographic Algorithm Identifier
+ Allocation for DNSSEC", RFC 6014, DOI 10.17487/RFC6014,
+ November 2010, <https://www.rfc-editor.org/info/rfc6014>.
+
+ [RFC6605] Hoffman, P. and W.C.A. Wijngaards, "Elliptic Curve Digital
+ Signature Algorithm (DSA) for DNSSEC", RFC 6605,
+ DOI 10.17487/RFC6605, April 2012,
+ <https://www.rfc-editor.org/info/rfc6605>.
+
+ [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
+ of Named Entities (DANE) Transport Layer Security (TLS)
+ Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August
+ 2012, <https://www.rfc-editor.org/info/rfc6698>.
+
+ [RFC6725] Rose, S., "DNS Security (DNSSEC) DNSKEY Algorithm IANA
+ Registry Updates", RFC 6725, DOI 10.17487/RFC6725, August
+ 2012, <https://www.rfc-editor.org/info/rfc6725>.
+
+ [RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC
+ Operational Practices, Version 2", RFC 6781,
+ DOI 10.17487/RFC6781, December 2012,
+ <https://www.rfc-editor.org/info/rfc6781>.
+
+ [RFC6975] Crocker, S. and S. Rose, "Signaling Cryptographic
+ Algorithm Understanding in DNS Security Extensions
+ (DNSSEC)", RFC 6975, DOI 10.17487/RFC6975, July 2013,
+ <https://www.rfc-editor.org/info/rfc6975>.
+
+ [RFC7129] Gieben, R. and W. Mekking, "Authenticated Denial of
+ Existence in the DNS", RFC 7129, DOI 10.17487/RFC7129,
+ February 2014, <https://www.rfc-editor.org/info/rfc7129>.
+
+ [RFC7344] Kumari, W., Gudmundsson, O., and G. Barwood, "Automating
+ DNSSEC Delegation Trust Maintenance", RFC 7344,
+ DOI 10.17487/RFC7344, September 2014,
+ <https://www.rfc-editor.org/info/rfc7344>.
+
+ [RFC7583] Morris, S., Ihren, J., Dickinson, J., and W. Mekking,
+ "DNSSEC Key Rollover Timing Considerations", RFC 7583,
+ DOI 10.17487/RFC7583, October 2015,
+ <https://www.rfc-editor.org/info/rfc7583>.
+
+ [RFC7646] Ebersman, P., Kumari, W., Griffiths, C., Livingood, J.,
+ and R. Weber, "Definition and Use of DNSSEC Negative Trust
+ Anchors", RFC 7646, DOI 10.17487/RFC7646, September 2015,
+ <https://www.rfc-editor.org/info/rfc7646>.
+
+ [RFC7958] Abley, J., Schlyter, J., Bailey, G., and P. Hoffman,
+ "DNSSEC Trust Anchor Publication for the Root Zone",
+ RFC 7958, DOI 10.17487/RFC7958, August 2016,
+ <https://www.rfc-editor.org/info/rfc7958>.
+
+ [RFC8027] Hardaker, W., Gudmundsson, O., and S. Krishnaswamy,
+ "DNSSEC Roadblock Avoidance", BCP 207, RFC 8027,
+ DOI 10.17487/RFC8027, November 2016,
+ <https://www.rfc-editor.org/info/rfc8027>.
+
+ [RFC8078] Gudmundsson, O. and P. Wouters, "Managing DS Records from
+ the Parent via CDS/CDNSKEY", RFC 8078,
+ DOI 10.17487/RFC8078, March 2017,
+ <https://www.rfc-editor.org/info/rfc8078>.
+
+ [RFC8080] Sury, O. and R. Edmonds, "Edwards-Curve Digital Security
+ Algorithm (EdDSA) for DNSSEC", RFC 8080,
+ DOI 10.17487/RFC8080, February 2017,
+ <https://www.rfc-editor.org/info/rfc8080>.
+
+ [RFC8145] Wessels, D., Kumari, W., and P. Hoffman, "Signaling Trust
+ Anchor Knowledge in DNS Security Extensions (DNSSEC)",
+ RFC 8145, DOI 10.17487/RFC8145, April 2017,
+ <https://www.rfc-editor.org/info/rfc8145>.
+
+ [RFC8198] Fujiwara, K., Kato, A., and W. Kumari, "Aggressive Use of
+ DNSSEC-Validated Cache", RFC 8198, DOI 10.17487/RFC8198,
+ July 2017, <https://www.rfc-editor.org/info/rfc8198>.
+
+ [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
+ Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499,
+ January 2019, <https://www.rfc-editor.org/info/rfc8499>.
+
+ [RFC8509] Huston, G., Damas, J., and W. Kumari, "A Root Key Trust
+ Anchor Sentinel for DNSSEC", RFC 8509,
+ DOI 10.17487/RFC8509, December 2018,
+ <https://www.rfc-editor.org/info/rfc8509>.
+
+ [RFC8624] Wouters, P. and O. Sury, "Algorithm Implementation
+ Requirements and Usage Guidance for DNSSEC", RFC 8624,
+ DOI 10.17487/RFC8624, June 2019,
+ <https://www.rfc-editor.org/info/rfc8624>.
+
+ [RFC8901] Huque, S., Aras, P., Dickinson, J., Vcelak, J., and D.
+ Blacka, "Multi-Signer DNSSEC Models", RFC 8901,
+ DOI 10.17487/RFC8901, September 2020,
+ <https://www.rfc-editor.org/info/rfc8901>.
+
+ [RFC9077] van Dijk, P., "NSEC and NSEC3: TTLs and Aggressive Use",
+ RFC 9077, DOI 10.17487/RFC9077, July 2021,
+ <https://www.rfc-editor.org/info/rfc9077>.
+
+ [RFC9157] Hoffman, P., "Revised IANA Considerations for DNSSEC",
+ RFC 9157, DOI 10.17487/RFC9157, December 2021,
+ <https://www.rfc-editor.org/info/rfc9157>.
+
+ [RFC9276] Hardaker, W. and V. Dukhovni, "Guidance for NSEC3
+ Parameter Settings", BCP 236, RFC 9276,
+ DOI 10.17487/RFC9276, August 2022,
+ <https://www.rfc-editor.org/info/rfc9276>.
+
+Acknowledgements
+
+ The DNS world owes a depth of gratitude to the authors and other
+ contributors to the core DNSSEC documents and to the notable DNSSEC
+ extensions.
+
+ In addition, the following people made significant contributions to
+ early draft versions of this document: Ben Schwartz and Duane
+ Wessels.
+
+Author's Address
+
+ Paul Hoffman
+ ICANN
+ Email: paul.hoffman@icann.org