Revised IANA Considerations for DNSSECICANNpaul.hoffman@icann.orgInternet-DraftThis document changes the review requirements needed to get some DNSSEC algorithms
and resource records added to IANA registries.
It updates RFC 6014 to include hash algorithms for DS records and NSEC3 parameters.
It also updates RFC 5155 and RFC 6014, which have requirements for DNSSEC
algorithms.
It also updates RFC 8624 to say that algorithms that are described in RFCs that
are not on standards track are only at the “MAY” level of implementation recommendation.
The rationale for these changes is to bring the requirements for DS records
and for the hash algorithms used in NSEC3 in line with the requirements for
all other DNSSEC algorithms.DNSSEC is primarily described in , , and .
DNSSEC commonly uses two resource records beyond those defined in RFC 4034:
DS and NSEC3 . describes the requirements for listing in the myriad IANA registries. updated the requirements for how DNSSEC cryptographic algorithm
identifiers in the IANA registries are allocated, reducing the requirements
from being “Standards Action” to “RFC Required”.
However, the IANA registry requirements for hash algorithms for DS records
and for the hash algorithms used in NSEC3 are still “Standards Action”. updates RFC 6014 to bring the requirements for DS records
and NSEC3 hash algorithms in line with the rest of the DNSSEC cryptographic algorithms
by allowing any DS or NSEC3 hash algorithms that are fully described in an RFC
to have identifiers allocated in the IANA registries.
This is an addition to the IANA considerations in RFC 6014.This document updates for all DNSKEY and DS algorithms that are not
on standards track.The second paragraph of Section 1.2 of RFC 8624 currently says:That paragraph is now replaced with the following:This document provides recommendations with respect to mandatory-to-implement
algorithms, algorithms so weak that they cannot be recommended, and algorithms
that are defined in RFCs that are not on standards track.
Any algorithm listed in the [DNSKEY-IANA] and [DS-IANA] registries that are not
mentioned in this document MAY be implemented.
For clarification and consistency, an algorithm will be specified as MAY in this
document only when it has been downgraded from a MUST or a RECOMMENDED to a MAY.This update is also reflected in the IANA considerations in .In the “Domain Name System Security (DNSSEC) NextSECure3 (NSEC3) Parameters”
registry, the registration procedure for “DNSSEC NSEC3 Flags”, “DNSSEC NSEC3
Hash Algorithms”, and “DNSSEC NSEC3PARAM Flags” are changed from “Standards
Action” to “RFC Required”.In the “Delegation Signer (DS) Resource Record (RR) Type Digest Algorithms”
registry, the registration procedure for “Digest Algorithms” is changed from
“Standards Action” to “RFC Required”.Changing the requirements for getting security algorithms added to IANA
registries as described in this document will make it easier to get good
algorithms added to the registries, and will make it easier to get bad
algorithms added to the registries.
It is impossible to weigh the security impact of those two changes.DNS Security Introduction and RequirementsThe 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]Resource Records for the DNS Security ExtensionsThis 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]Protocol Modifications for the DNS Security ExtensionsThis 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]DNS Security (DNSSEC) Hashed Authenticated Denial of ExistenceThe 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]Cryptographic Algorithm Identifier Allocation for DNSSECThis 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]Guidelines for Writing an IANA Considerations Section in RFCsMany protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA).To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry.This is the third edition of this document; it obsoletes RFC 5226.Algorithm Implementation Requirements and Usage Guidance for DNSSECThe 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.Delegation Signer (DS) Resource Record (RR)The delegation signer (DS) resource record (RR) is inserted at a zone cut (i.e., a delegation point) to indicate that the delegated zone is digitally signed and that the delegated zone recognizes the indicated key as a valid zone key for the delegated zone. The DS RR is a modification to the DNS Security Extensions definition, motivated by operational considerations. The intent is to use this resource record as an explicit statement about the delegation, rather than relying on inference. This document defines the DS RR, gives examples of how it is used and describes the implications on resolvers. This change is not backwards compatible with RFC 2535. This document updates RFC 1035, RFC 2535, RFC 3008 and RFC 3090.