]> ICANN

paul.hoffman@icann.org

Internet-Draft This document describes the DNS security extensions (commonly called "DNSSEC") that are specified RFCs 4033, 4034, 4035, and 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. Another purpose is to move DNSSEC to Best Current Practice status. This document is currently maintained at https://github.com/paulehoffman/draft-hoffman-dnssec. Issues and pull requests are welcomed.

Introduction The core specification for what we know as DNSSEC (the combination of , , and ) describes a set of protocols that provide origin authentication to data in the DNS. updates and extends those core RFCs, but does not fundamentally change the way that DNSSEC works. This document lists many (but not all) of the RFCs that should be considered by someone creating an implementation of, or someone deploying, modern DNSSEC. It uses terminology from those documents without defining that terminology. It also points to the relevant IANA registries that relate to DNSSEC. It does not, however, point to standards that rely on zones needing to be signed by DNSSEC.

DNSSEC as a Best Current Practice The DNSSEC set of protocols is widely considered the best current practice for adding origin authentication of data in the DNS. To date, no standards-track RFCs offer any other method for such origin authentication of data in the DNS. Some observers note that, 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 web sites are signed, and only around a third of queries to recursive resolvers are validated. However, this low level of implementation does not affect whether 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 within some top-level domains (TLDs), and the near-universal deployment of DNSSEC in the TLDs, demonstrate that DNSSEC is suitable for implementation by both ordinary and highly sophisticated domain owners.

Implementing DNSSEC Developers of validating resolvers and authoritative servers, as well as operators of 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.

DNSSEC Core Documents What we today call "DNSSEC" is formally version 3 of the DNSSEC specification. However, earlier versions of DNSSEC were thinly deployed and significantly less visible than the current DNSSEC specification. Throughout this document, "DNSSEC" means the version of the protocol initially defined in , , and . The three initial core documents generally cover different topics: is an overview of DNSSEC, including how it might change the resolution of DNS queries. specifies the DNS resource records used in DNSSEC. It obsoletes many RFCs for earlier versions of DNSSEC. 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 an DNSSEC-aware authoritative server, and/or a DNSSEC-aware recursive resolver from the three core documents plus a few older RFCs specifying the cryptography used. Those two older documents are: defines how to use the DSA signature algorithm (although refers to other documents for the details). DSA was thinly implemented and can safely be ignored by DNSSEC implementations defines how to use the RSA signature algorithm (although refers to other documents for the details). RSA is still the most popular signing algorithm for DNSSEC.

Addition to the DNSSEC Core As with any major protocol, developers and operators discovered issues with the original core documents over the years. 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. brings a few additions into the core of DNSSEC. It makes NSEC3 as much a part of DNSSEC as NSEC is. It also makes the SHA-2 hash function defined in and part of the core as well.

Additional Cryptographic Algorithms and DNSSEC Cryptography improves over time, and new algorithms get adopted by various Internet protocols. Two new signing algorithms have been adopted by the DNSSEC community: ECDSA and EdDSA . The GOST signing algorithm 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 . Note that this specification is only about what algorithms should and should not be included in implementations: it is not advice for which algorithms that zone operators should and should not sign with, nor which algorithms recursive resolver operators should or should not validate.

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: explains how recursive resolvers and the DNS root can work together to automate the rollover of the root's key signing key (KSK). is a compendium of operational practices that may not be obvious from reading just the core specifications. describes using the CDS and CDNSKEY resource records to help automate the creation of DS records in the parents of signed zones. extends by showing how to do initial setup of trusted relationships between signed parent and child zones. describes how a validating resolver can emit fewer queries in signed zones that use NSEC for negative caching. updates with respect to the time-to-live (TTL) fields in signed records.

IANA Considerations IANA already has three registries 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 and . This document does not create any new IANA considerations.

Security Considerations All of the security considerations from all of the RFCs referenced in this document apply here.

This document describes how to produce RSA/SHA1 SIG resource records (RRs) in Section 3 and, so as to completely replace RFC 2537, describes how to produce RSA KEY RRs in Section 2. [STANDARDS-TRACK] The Domain Name System Security Extensions (DNSSEC) add data origin authentication and data integrity to the Domain Name System. This document introduces these extensions and describes their capabilities and limitations. This document also discusses the services that the DNS security extensions do and do not provide. Last, this document describes the interrelationships between the documents that collectively describe DNSSEC. [STANDARDS-TRACK] This document is part of a family of documents that describe the DNS Security Extensions (DNSSEC). The DNS Security Extensions are a collection of resource records and protocol modifications that provide source authentication for the DNS. This document defines the public key (DNSKEY), delegation signer (DS), resource record digital signature (RRSIG), and authenticated denial of existence (NSEC) resource records. The purpose and format of each resource record is described in detail, and an example of each resource record is given. This document obsoletes RFC 2535 and incorporates changes from all updates to RFC 2535. [STANDARDS-TRACK] This document is part of a family of documents that describe the DNS Security Extensions (DNSSEC). The DNS Security Extensions are a collection of new resource records and protocol modifications that add data origin authentication and data integrity to the DNS. This document describes the DNSSEC protocol modifications. This document defines the concept of a signed zone, along with the requirements for serving and resolving by using DNSSEC. These techniques allow a security-aware resolver to authenticate both DNS resource records and authoritative DNS error indications. This document obsoletes RFC 2535 and incorporates changes from all updates to RFC 2535. [STANDARDS-TRACK] This document specifies how to use the SHA-256 digest type in DNS Delegation Signer (DS) Resource Records (RRs). DS records, when stored in a parent zone, point to DNSKEYs in a child zone. [STANDARDS-TRACK] The Domain Name System Security (DNSSEC) Extensions introduced the NSEC resource record (RR) for authenticated denial of existence. This document introduces an alternative resource record, NSEC3, which similarly provides authenticated denial of existence. However, it also provides measures against zone enumeration and permits gradual expansion of delegation-centric zones. [STANDARDS-TRACK] This document describes how to produce RSA/SHA-256 and RSA/SHA-512 DNSKEY and RRSIG resource records for use in the Domain Name System Security Extensions (RFC 4033, RFC 4034, and RFC 4035). [STANDARDS TRACK] This document is a collection of technical clarifications to the DNS Security (DNSSEC) document set. It is meant to serve as a resource to implementors as well as a collection of DNSSEC errata that existed at the time of writing.This document updates the core DNSSEC documents (RFC 4033, RFC 4034, and RFC 4035) as well as the NSEC3 specification (RFC 5155). It also defines NSEC3 and SHA-2 (RFC 4509 and RFC 5702) as core parts of the DNSSEC specification. A standard method for storing US Government Digital Signature Algorithm keys and signatures in the Domain Name System is described which utilizes DNS KEY and SIG resource records. [STANDARDS-TRACK] This document describes a means for automated, authenticated, and authorized updating of DNSSEC "trust anchors". The method provides protection against N-1 key compromises of N keys in the trust point key set. Based on the trust established by the presence of a current anchor, other anchors may be added at the same place in the hierarchy, and, ultimately, supplant the existing anchor(s).This mechanism will require changes to resolver management behavior (but not resolver resolution behavior), and the addition of a single flag bit to the DNSKEY record. [STANDARDS-TRACK] This document describes how to produce digital signatures and hash functions using the GOST R 34.10-2001 and GOST R 34.11-94 algorithms for DNSKEY, RRSIG, and DS resource records, for use in the Domain Name System Security Extensions (DNSSEC). [STANDARDS-TRACK] This document specifies how DNSSEC cryptographic algorithm identifiers in the IANA registries are allocated. It changes the requirement from "standard required" to "RFC Required". It does not change the list of algorithms that are recommended or required for DNSSEC implementations. [STANDARDS-TRACK] This document describes how to specify Elliptic Curve Digital Signature Algorithm (DSA) keys and signatures in DNS Security (DNSSEC). It lists curves of different sizes and uses the SHA-2 family of hashes for signatures. [STANDARDS-TRACK] This document describes a set of practices for operating the DNS with security extensions (DNSSEC). The target audience is zone administrators deploying DNSSEC.The document discusses operational aspects of using keys and signatures in the DNS. It discusses issues of key generation, key storage, signature generation, key rollover, and related policies.This document obsoletes RFC 4641, as it covers more operational ground and gives more up-to-date requirements with respect to key sizes and the DNSSEC operations. This document describes a method to allow DNS Operators to more easily update DNSSEC Key Signing Keys using the DNS as a communication channel. The technique described is aimed at delegations in which it is currently hard to move information from the Child to Parent. RFC 7344 specifies how DNS trust can be maintained across key rollovers in-band between parent and child. This document elevates RFC 7344 from Informational to Standards Track. It also adds a method for initial trust setup and removal of a secure entry point.Changing a domain's DNSSEC status can be a complicated matter involving multiple unrelated parties. Some of these parties, such as the DNS operator, might not even be known by all the organizations involved. The inability to disable DNSSEC via in-band signaling is seen as a problem or liability that prevents some DNSSEC adoption at a large scale. This document adds a method for in-band signaling of these DNSSEC status changes.This document describes reasonable policies to ease deployment of the initial acceptance of new secure entry points (DS records).It is preferable that operators collaborate on the transfer or move of a domain. The best method is to perform a Key Signing Key (KSK) plus Zone Signing Key (ZSK) rollover. If that is not possible, the method using an unsigned intermediate state described in this document can be used to move the domain between two parties. This leaves the domain temporarily unsigned and vulnerable to DNS spoofing, but that is preferred over the alternative of validation failures due to a mismatched DS and DNSKEY record. This document describes how to specify Edwards-curve Digital Security Algorithm (EdDSA) keys and signatures in DNS Security (DNSSEC). It uses EdDSA with the choice of two curves: Ed25519 and Ed448. The DNS relies upon caching to scale; however, the cache lookup generally requires an exact match. This document specifies the use of NSEC/NSEC3 resource records to allow DNSSEC-validating resolvers to generate negative answers within a range and positive answers from wildcards. This increases performance, decreases latency, decreases resource utilization on both authoritative and recursive servers, and increases privacy. Also, it may help increase resilience to certain DoS attacks in some circumstances.This document updates RFC 4035 by allowing validating resolvers to generate negative answers based upon NSEC/NSEC3 records and positive answers in the presence of wildcards. The DNSSEC protocol makes use of various cryptographic algorithms in order to provide authentication of DNS data and proof of nonexistence. To ensure interoperability between DNS resolvers and DNS authoritative servers, it is necessary to specify a set of algorithm implementation requirements and usage guidelines to ensure that there is at least one algorithm that all implementations support. This document defines the current algorithm implementation requirements and usage guidance for DNSSEC. This document obsoletes RFC 6944. Due to a combination of unfortunate wording in earlier documents, aggressive use of NSEC and NSEC3 records may deny the existence of names far beyond the intended lifetime of a denial. This document changes the definition of the NSEC and NSEC3 TTL to correct that situation. This document updates RFCs 4034, 4035, 5155, and 8198. This document changes the review requirements needed to get DNSSEC algorithms and resource records added to IANA registries. It updates RFC 6014 to include hash algorithms for Delegation Signer (DS) records and NextSECure version 3 (NSEC3) parameters (for Hashed Authenticated Denial of Existence). It also updates RFCs 5155 and 6014, which have requirements for DNSSEC algorithms, and updates RFC 8624 to clarify the implementation recommendation related to the algorithms described in RFCs that are not on the standards track. The rationale for these changes is to bring the requirements for DS records and hash algorithms used in NSEC3 in line with the requirements for all other DNSSEC algorithms.

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 versions of this document: Ben Schwartz and Duane Wessels.