rfc9157xml2.original.xml   rfc9157.xml 
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.5.6 -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;">
]> ]>
<?rfc toc="yes"?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
<?rfc tocdepth="4"?> -ietf-dnsop-dnssec-iana-cons-05" number="9157" updates="5155, 6014, 8624" obsole
<?rfc sortrefs="yes"?> tes="" submissionType="IETF" category="std" consensus="true" xml:lang="en" tocIn
<?rfc symrefs="yes"?> clude="true" tocDepth="4" sortRefs="true" symRefs="true" version="3">
<rfc ipr="trust200902" docName="draft-ietf-dnsop-dnssec-iana-cons-05" category="
std" consensus="true" updates="5155, 6014, 8624">
<front> <front>
<title abbrev="IANA revisions for DNSSEC">Revised IANA Considerations for DN <title abbrev="IANA Revisions for DNSSEC">Revised IANA Considerations for DN
SSEC</title> SSEC</title>
<seriesInfo name="RFC" value="9157"/>
<author initials="P." surname="Hoffman" fullname="Paul Hoffman"> <author initials="P." surname="Hoffman" fullname="Paul Hoffman">
<organization>ICANN</organization> <organization>ICANN</organization>
<address> <address>
<email>paul.hoffman@icann.org</email> <email>paul.hoffman@icann.org</email>
</address> </address>
</author> </author>
<date year="2021" month="November"/>
<date year="2021" month="October" day="07"/> <abstract>
<keyword>Internet-Draft</keyword>
<abstract>
<t>This document changes the review requirements needed to get DNSSEC algorithms <t>This document changes the review requirements needed to get DNSSEC algo
and resource records added to IANA registries. rithms
It updates RFC 6014 to include hash algorithms for DS (Delegation Signer) record and resource records added to IANA registries.
s It updates RFC 6014 to include hash algorithms for Delegation Signer (DS) record
and NSEC3 (Hashed Authenticated Denial of Existence) parameters. s
It also updates RFC 5155 and RFC 6014, which have requirements for DNSSEC and NextSECure version 3 (NSEC3) parameters (for Hashed Authenticated Denial of
algorithms, and Existence). It also updates RFCs 5155 and 6014, which have requirements for DNSS
updates RFC 8624 to say that algorithms that are described in RFCs that EC
are not on standards track are only at the “MAY” level of implementation recomme algorithms, and updates RFC 8624 to clarify the implementation recommendation re
ndation. lated 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 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 and hash algorithms used in NSEC3 in line with the requirements for
all other DNSSEC algorithms.</t> all other DNSSEC algorithms.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="introduction" numbered="true" toc="default">
<section anchor="introduction" title="Introduction"> <name>Introduction</name>
<t>DNSSEC is primarily described in <xref target="RFC4033" format="default
<t>DNSSEC is primarily described in <xref target="RFC4033"/>, <xref target="RFC4 "/>, <xref target="RFC4034" format="default"/>, and <xref target="RFC4035" forma
034"/>, and <xref target="RFC4035"/>. t="default"/>.
DNSSEC commonly uses another resource record beyond those defined in RFC 4034: DNSSEC commonly uses another resource record beyond those defined in <xref targe
NSEC3 <xref target="RFC5155"/>. t="RFC4034"/>:
DS resrouce records were originally defined in <xref target="RFC3658"/>, and tha NSEC3 <xref target="RFC5155" format="default"/>.
t definition DS resource records were originally defined in <xref target="RFC3658" format="de
was obsoleted by RFC 4034.</t> fault"/>, and that definition
was obsoleted by <xref target="RFC4034"/>.</t>
<t><xref target="RFC6014"/> updated the requirements for how DNSSEC cryptographi <t><xref target="RFC6014" format="default"/> updates the requirements for
c algorithm how DNSSEC cryptographic algorithm
identifiers in the IANA registries are assigned, reducing the requirements identifiers in the IANA registries are assigned, reducing the requirements
from being “Standards Action” to “RFC Required”. from "Standards Action" to "RFC Required".
However, the IANA registry requirements for hash algorithms for DS records However, the IANA registry requirements for hash algorithms for DS records
<xref target="RFC3658"/> <xref target="RFC3658" format="default"/>
and for the hash algorithms used in NSEC3 records <xref target="RFC5155"/> are s and for the hash algorithms used in NSEC3 records <xref target="RFC5155" format=
till “Standards Action”. "default"/> are still "Standards Action".
This document updates those IANA registry requirements. This document updates those IANA registry requirements.
(For reference on how IANA registries can be updated in general, see <xref targe (For a reference on how IANA registries can be updated in general, see <xr
t="RFC8126"/>.)</t> ef target="RFC8126" format="default"/>.)</t>
<section numbered="true" toc="default">
<t>The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, <name>Requirements Language</name>
“SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, <t>
and “OPTIONAL” in this document are to be interpreted as described in The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, th IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
ey NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
appear in all capitals, as shown here.</t> RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
</section> be interpreted as
<section anchor="update-to-rfc-6014" title="Update to RFC 6014"> described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
<t><xref target="iana"/> updates RFC 6014 to bring the requirements for DS recor </t>
ds </section>
</section>
<section anchor="update-to-rfc-6014" numbered="true" toc="default">
<name>Update to RFC 6014</name>
<t><xref target="iana" format="default"/> updates <xref target="RFC6014"/>
to bring the requirements for DS records
and NSEC3 hash algorithms in line with the rest of the DNSSEC cryptographic algo rithms and NSEC3 hash algorithms in line with the rest of the DNSSEC cryptographic algo rithms
by allowing any DS hash algorithms, NSEC3 hash algorithms, by allowing any DS hash algorithms, NSEC3 hash algorithms,
NSEC3 parameters, and NSEC3 flags that are fully described in an RFC NSEC3 parameters, and NSEC3 flags that are fully described in an RFC
to have identifiers assigned in the IANA registries. to have identifiers assigned in the IANA registries.
This is an addition to the IANA considerations in RFC 6014.</t> This is an addition to the IANA considerations in <xref target="RFC6014"/>.</t>
</section>
</section> <section anchor="update-to-rfc-8624" numbered="true" toc="default">
<section anchor="update-to-rfc-8624" title="Update to RFC 8624"> <name>Update to RFC 8624</name>
<t>This document updates <xref target="RFC8624" format="default"/> for all
<t>This document updates <xref target="RFC8624"/> for all DNSKEY and DS algorith DNSKEY and DS algorithms that are not
ms that are not on the standards track.</t>
on standards track.</t> <t>The second paragraph of <xref target="RFC8624" sectionFormat="of" secti
on="1.2"/> currently says:</t>
<t>The second paragraph of Section 1.2 of RFC 8624 currently says:</t> <blockquote><t>
<figure><artwork><![CDATA[
This document only provides recommendations with respect to This document only provides recommendations with respect to
mandatory-to-implement algorithms or algorithms so weak that they mandatory-to-implement algorithms or algorithms so weak that they
cannot be recommended. Any algorithm listed in the [DNSKEY-IANA] cannot be recommended. Any algorithm listed in the [DNSKEY-IANA]
and [DS-IANA] registries that are not mentioned in this document and [DS-IANA] registries that are not mentioned in this document
MAY be implemented. For clarification and consistency, an <bcp14>MAY</bcp14> be implemented. For clarification and consistency, an
algorithm will be specified as MAY in this document only when it algorithm will be specified as <bcp14>MAY</bcp14> in this document only when
has been downgraded from a MUST or a RECOMMENDED to a MAY. it
]]></artwork></figure> has been downgraded from a <bcp14>MUST</bcp14> or a <bcp14>RECOMMENDED</bcp14
> to a <bcp14>MAY</bcp14>.</t>
<t>That paragraph is now replaced with the following:</t> </blockquote>
<t>That paragraph is now replaced with the following:</t>
<figure><artwork><![CDATA[ <blockquote><t>
This document provides recommendations with respect to This document provides recommendations with respect to
mandatory-to-implement algorithms, algorithms so weak that they mandatory-to-implement algorithms, algorithms so weak that they
cannot be recommended, and algorithms that are defined in RFCs cannot be recommended, and algorithms defined in RFCs
that are not on standards track. Any algorithm listed in the that are not on the standards track. Any algorithm listed in the
[DNSKEY-IANA] and [DS-IANA] registries that are not mentioned in [DNSKEY-IANA] and [DS-IANA] registries that are not mentioned in
this document MAY be implemented. For clarification and this document <bcp14>MAY</bcp14> be implemented. For clarification and
consistency, an algorithm will be specified as MAY in this consistency, an algorithm will be specified as <bcp14>MAY</bcp14> in this doc
document only when it has been downgraded from a MUST or a ument only when it has been downgraded from a <bcp14>MUST</bcp14> or a
RECOMMENDED to a MAY. <bcp14>RECOMMENDED</bcp14> to a <bcp14>MAY</bcp14>.</t>
]]></artwork></figure> </blockquote>
<t>This update is also reflected in the IANA considerations in <xref targe
<t>This update is also reflected in the IANA considerations in <xref target="ian t="iana" format="default"/>.</t>
a"/>.</t> </section>
<section anchor="iana" numbered="true" toc="default">
</section> <name>IANA Considerations</name>
<section anchor="iana" title="IANA Considerations"> <t>In the "Domain Name System Security (DNSSEC) NextSECure3 (NSEC3) Parame
ters"
<t>In the “Domain Name System Security (DNSSEC) NextSECure3 (NSEC3) Parameters” registry, the registration procedure for "DNSSEC NSEC3 Flags", "DNSSEC NSEC3
registry, the registration procedure for “DNSSEC NSEC3 Flags”, “DNSSEC NSEC3 Hash Algorithms", and "DNSSEC NSEC3PARAM Flags" has been changed from "Standards
Hash Algorithms”, and “DNSSEC NSEC3PARAM Flags” are changed from “Standards Action" to "RFC Required", and this document has been added as a reference.</t>
Action” to “RFC Required”.</t> <t>In the "DNSSEC Delegation Signer (DS) Resource Record (RR) Type Digest
Algorithms" registry, the registration procedure for "Digest Algorithms" has bee
<t>In the “Delegation Signer (DS) Resource Record (RR) Type Digest Algorithms” n changed from "Standards Action" to "RFC Required", and this document has been
registry, the registration procedure for “Digest Algorithms” is changed from added as a reference.</t>
“Standards Action” to “RFC Required”.</t> </section>
<section anchor="security-considerations" numbered="true" toc="default">
</section> <name>Security Considerations</name>
<section anchor="security-considerations" title="Security Considerations"> <t>Changing the requirements for adding security algorithms to IANA
registries as described in this document will make it easier to add both good
<t>Changing the requirements for getting security algorithms added to IANA and bad algorithms to the registries.
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.</t> It is impossible to weigh the security impact of those two changes.</t>
<t>Administrators of DNSSEC-signed zones and validating resolvers may have
<t>Administrators of DNSSEC-signed zones, and of validating resolvers, may have been making
been making
security decisions based on the contents of the IANA registries. security decisions based on the contents of the IANA registries.
This was a bad idea in the past, and now is an even worse idea because there wil l be more This was a bad idea in the past, and now it is an even worse idea because there will be more
algorithms in those registries that may not have gone through IETF review. algorithms in those registries that may not have gone through IETF review.
Security decisions about which algorithms are safe and not safe should be made b y Security decisions about which algorithms are safe and not safe should be made b y
reading the security literature, not by looking in IANA registries.</t> reading the security literature, not by looking in IANA registries.</t>
</section>
</section>
</middle> </middle>
<back> <back>
<references>
<references title='Normative References'> <name>References</name>
<references>
<reference anchor='RFC2119' target='https://www.rfc-editor.org/info/rfc2119'> <name>Normative References</name>
<front> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<title>Key words for use in RFCs to Indicate Requirement Levels</title> FC.2119.xml"/>
<author fullname='S. Bradner' initials='S.' surname='Bradner'><organization/></a <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
uthor> FC.4033.xml"/>
<date month='March' year='1997'/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<abstract><t>In many standards track documents several words are used to signify FC.4034.xml"/>
the requirements in the specification. These words are often capitalized. This <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
document defines these words as they should be interpreted in IETF documents. FC.4035.xml"/>
This document specifies an Internet Best Current Practices for the Internet Comm <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
unity, and requests discussion and suggestions for improvements.</t></abstract> FC.5155.xml"/>
</front> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<seriesInfo name='BCP' value='14'/> FC.6014.xml"/>
<seriesInfo name='RFC' value='2119'/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<seriesInfo name='DOI' value='10.17487/RFC2119'/> FC.8126.xml"/>
</reference> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8174.xml"/>
<reference anchor='RFC4033' target='https://www.rfc-editor.org/info/rfc4033'> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<front> FC.8624.xml"/>
<title>DNS Security Introduction and Requirements</title> </references>
<author fullname='R. Arends' initials='R.' surname='Arends'><organization/></aut <references>
hor> <name>Informative References</name>
<author fullname='R. Austein' initials='R.' surname='Austein'><organization/></a <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
uthor> FC.3658.xml"/>
<author fullname='M. Larson' initials='M.' surname='Larson'><organization/></aut </references>
hor>
<author fullname='D. Massey' initials='D.' surname='Massey'><organization/></aut
hor>
<author fullname='S. Rose' initials='S.' surname='Rose'><organization/></author>
<date month='March' year='2005'/>
<abstract><t>The Domain Name System Security Extensions (DNSSEC) add data origin
authentication and data integrity to the Domain Name System. This document int
roduces 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]</t></abstract>
</front>
<seriesInfo name='RFC' value='4033'/>
<seriesInfo name='DOI' value='10.17487/RFC4033'/>
</reference>
<reference anchor='RFC4034' target='https://www.rfc-editor.org/info/rfc4034'>
<front>
<title>Resource Records for the DNS Security Extensions</title>
<author fullname='R. Arends' initials='R.' surname='Arends'><organization/></aut
hor>
<author fullname='R. Austein' initials='R.' surname='Austein'><organization/></a
uthor>
<author fullname='M. Larson' initials='M.' surname='Larson'><organization/></aut
hor>
<author fullname='D. Massey' initials='D.' surname='Massey'><organization/></aut
hor>
<author fullname='S. Rose' initials='S.' surname='Rose'><organization/></author>
<date month='March' year='2005'/>
<abstract><t>This document is part of a family of documents that describe the DN
S 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 exis
tence (NSEC) resource records. The purpose and format of each resource record i
s described in detail, and an example of each resource record is given. </t><t>
This document obsoletes RFC 2535 and incorporates changes from all updates to RF
C 2535. [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='4034'/>
<seriesInfo name='DOI' value='10.17487/RFC4034'/>
</reference>
<reference anchor='RFC4035' target='https://www.rfc-editor.org/info/rfc4035'>
<front>
<title>Protocol Modifications for the DNS Security Extensions</title>
<author fullname='R. Arends' initials='R.' surname='Arends'><organization/></aut
hor>
<author fullname='R. Austein' initials='R.' surname='Austein'><organization/></a
uthor>
<author fullname='M. Larson' initials='M.' surname='Larson'><organization/></aut
hor>
<author fullname='D. Massey' initials='D.' surname='Massey'><organization/></aut
hor>
<author fullname='S. Rose' initials='S.' surname='Rose'><organization/></author>
<date month='March' year='2005'/>
<abstract><t>This document is part of a family of documents that describe the DN
S Security Extensions (DNSSEC). The DNS Security Extensions are a collection of
new resource records and protocol modifications that add data origin authentica
tion 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 al
low a security-aware resolver to authenticate both DNS resource records and auth
oritative DNS error indications. </t><t> This document obsoletes RFC 2535 and in
corporates changes from all updates to RFC 2535. [STANDARDS-TRACK]</t></abstrac
t>
</front>
<seriesInfo name='RFC' value='4035'/>
<seriesInfo name='DOI' value='10.17487/RFC4035'/>
</reference>
<reference anchor='RFC5155' target='https://www.rfc-editor.org/info/rfc5155'>
<front>
<title>DNS Security (DNSSEC) Hashed Authenticated Denial of Existence</title>
<author fullname='B. Laurie' initials='B.' surname='Laurie'><organization/></aut
hor>
<author fullname='G. Sisson' initials='G.' surname='Sisson'><organization/></aut
hor>
<author fullname='R. Arends' initials='R.' surname='Arends'><organization/></aut
hor>
<author fullname='D. Blacka' initials='D.' surname='Blacka'><organization/></aut
hor>
<date month='March' year='2008'/>
<abstract><t>The Domain Name System Security (DNSSEC) Extensions introduced the
NSEC resource record (RR) for authenticated denial of existence. This document i
ntroduces an alternative resource record, NSEC3, which similarly provides authen
ticated denial of existence. However, it also provides measures against zone en
umeration and permits gradual expansion of delegation-centric zones. [STANDARDS
-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='5155'/>
<seriesInfo name='DOI' value='10.17487/RFC5155'/>
</reference>
<reference anchor='RFC6014' target='https://www.rfc-editor.org/info/rfc6014'>
<front>
<title>Cryptographic Algorithm Identifier Allocation for DNSSEC</title>
<author fullname='P. Hoffman' initials='P.' surname='Hoffman'><organization/></a
uthor>
<date month='November' year='2010'/>
<abstract><t>This document specifies how DNSSEC cryptographic algorithm identifi
ers in the IANA registries are allocated. It changes the requirement from &quot
;standard required&quot; to &quot;RFC Required&quot;. It does not change the li
st of algorithms that are recommended or required for DNSSEC implementations. [
STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='6014'/>
<seriesInfo name='DOI' value='10.17487/RFC6014'/>
</reference>
<reference anchor='RFC8126' target='https://www.rfc-editor.org/info/rfc8126'>
<front>
<title>Guidelines for Writing an IANA Considerations Section in RFCs</title>
<author fullname='M. Cotton' initials='M.' surname='Cotton'><organization/></aut
hor>
<author fullname='B. Leiba' initials='B.' surname='Leiba'><organization/></autho
r>
<author fullname='T. Narten' initials='T.' surname='Narten'><organization/></aut
hor>
<date month='June' year='2017'/>
<abstract><t>Many protocols make use of points of extensibility that use constan
ts to identify various protocol parameters. To ensure that the values in these
fields do not have conflicting uses and to promote interoperability, their alloc
ations are often coordinated by a central record keeper. For IETF protocols, th
at role is filled by the Internet Assigned Numbers Authority (IANA).</t><t>To ma
ke assignments in a given registry prudently, guidance describing the conditions
under which new values should be assigned, as well as when and how modification
s 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 addre
sses the various issues that are likely in the operation of a registry.</t><t>Th
is is the third edition of this document; it obsoletes RFC 5226.</t></abstract>
</front>
<seriesInfo name='BCP' value='26'/>
<seriesInfo name='RFC' value='8126'/>
<seriesInfo name='DOI' value='10.17487/RFC8126'/>
</reference>
<reference anchor='RFC8174' target='https://www.rfc-editor.org/info/rfc8174'>
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
<author fullname='B. Leiba' initials='B.' surname='Leiba'><organization/></autho
r>
<date month='May' year='2017'/>
<abstract><t>RFC 2119 specifies common key words that may be used in protocol s
pecifications. This document aims to reduce the ambiguity by clarifying that on
ly UPPERCASE usage of the key words have the defined special meanings.</t></abs
tract>
</front>
<seriesInfo name='BCP' value='14'/>
<seriesInfo name='RFC' value='8174'/>
<seriesInfo name='DOI' value='10.17487/RFC8174'/>
</reference>
<reference anchor='RFC8624' target='https://www.rfc-editor.org/info/rfc8624'>
<front>
<title>Algorithm Implementation Requirements and Usage Guidance for DNSSEC</titl
e>
<author fullname='P. Wouters' initials='P.' surname='Wouters'><organization/></a
uthor>
<author fullname='O. Sury' initials='O.' surname='Sury'><organization/></author>
<date month='June' year='2019'/>
<abstract><t>The DNSSEC protocol makes use of various cryptographic algorithms i
n order to provide authentication of DNS data and proof of nonexistence. To ens
ure interoperability between DNS resolvers and DNS authoritative servers, it is
necessary to specify a set of algorithm implementation requirements and usage gu
idelines to ensure that there is at least one algorithm that all implementations
support. This document defines the current algorithm implementation requiremen
ts and usage guidance for DNSSEC. This document obsoletes RFC 6944.</t></abstra
ct>
</front>
<seriesInfo name='RFC' value='8624'/>
<seriesInfo name='DOI' value='10.17487/RFC8624'/>
</reference>
</references>
<references title='Informative References'>
<reference anchor='RFC3658' target='https://www.rfc-editor.org/info/rfc3658'>
<front>
<title>Delegation Signer (DS) Resource Record (RR)</title>
<author fullname='O. Gudmundsson' initials='O.' surname='Gudmundsson'><organizat
ion/></author>
<date month='December' year='2003'/>
<abstract><t>The delegation signer (DS) resource record (RR) is inserted at a zo
ne cut (i.e., a delegation point) to indicate that the delegated zone is digital
ly signed and that the delegated zone recognizes the indicated key as a valid zo
ne key for the delegated zone. The DS RR is a modification to the DNS Security
Extensions definition, motivated by operational considerations. The intent is t
o 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, R
FC 3008 and RFC 3090.</t></abstract>
</front>
<seriesInfo name='RFC' value='3658'/>
<seriesInfo name='DOI' value='10.17487/RFC3658'/>
</reference>
</references> </references>
<section anchor="acknowledgements" numbered="false" toc="default">
<section anchor="acknowledgements" title="Acknowledgements"> <name>Acknowledgements</name>
<t><contact fullname="Donald Eastlake"/>, <contact fullname="Murray Kucher
<t>Donald Eastlake, Murray Kucherawy, Dan Harkins, Martin Duke, and awy"/>, <contact fullname="Dan Harkins"/>, <contact fullname="Martin Duke"/>, an
Benjamin Kaduk contributed to this document.</t> d
<contact fullname="Benjamin Kaduk"/> contributed to this document.</t>
</section> </section>
</back> </back>
<!-- ##markdown-source:
H4sIAIhZX2EAA61Y3W4btxK+51MQ6k0MSILt2Gnqq6NaDmwk/qnlXBTFQUHt
UhKPd5d7SK5VNXDQB+l5uT7J+Wa4u1r9xEiK3tjkkhzOfPPNDzUYDEQwIdNn
8l4/Ga9TeTW6GclzW3iTaqeCwUjOrJPjm8nk4lyo6dTpp7O4zdGZ7R2pTQqV
Q2Lq1CwMjA6zQVp4W9Jfr5OBUYUaJDg1ODwVwgdVpL+qzBY4ElylBS3pwlf+
TK60F8KUjld8OD48/OHwWDwucX8RtCt0GIzpFpGocCZ9SEVVpipoHD09Oj3t
yzeHRyd9+fbN8YkQpTkTUgabRLk8THUZFmfyBDNvXXB65ptVv8rXU6GqsLAO
AgZYkqbA97uhvLSzWa4K+hRtvlNV1v1q3Ry6no9ubmimc2WyM1li03ARN/3L
JKoohtgnRGFdDsSfNOl5/+78+Ojoh3p4cvj69Xp4sh6e1kMytx6SzfXw7dHx
m3b4ffsVcJwJU8y27nv95vTtmcBYDAYDqaY+OJUEIR4Wxku4tcp1EWSyUMVc
exkWmgmgl/j338o4TcteFlqn4FGwcq5DTQqpsrl1JixyL+BuHPC2cgkJSKxL
vVRpfabm1dzgcqP9UFwFWfuUVGSH0j5TJFmVarlQftGRHok4ka/GOtNzpq+c
mHmh3UFzFytwA6Vey1eXOI17R3AudIcrAmZjXRiVSTuTF79BDV0k+gA+c3Aw
OBdVUpm3G3oR/pIkN0r25XJhkgUUfNKbAHWjqVW8T4dFVyJ5iSz1agWsVeha
GedOy1T7xJkptDYFnYpLgpYKGySs5/hShDF585FP2SJbSUggF/auRz/3ZKaf
NJts8jJjPSN2hFmOacrTIagAY3isMs2WQIbXLSlAFKg8daaY1wTZNnyy4Yda
wo4bKx9Nin7CIDOFlkss7hULIKE9Vtwu4YaC6ZybNM20EN9R6nA2rRKyQoh6
PxQvncmVM4BmA9VPn+r4e37ut5MTmpABzYfT5+dhI4sgY4hhBahdRMW2OC+n
emUhAGnFkx9nMLDxoowxHo3nG4hefAPB552tOrGz1ORSZ+YGTmHtW1l8lsK6
UZeJwxsMm79UXtqpt5km5k9X7e1AjQ8TlZ+fa6qn+326sMsG9sStymDnTpUg
/9oJAsUE8TUziB/Si8RsRToTU3lPwZr2sQAP7WORmDmbAzxa601aco/YnT1i
X49suI9H0t5QXNol2O36O7eu9piyP500lO3g+Q30bRzV8SRb64MBbXeNGG5l
3CYrRKp82YKhePXOEtFmYASyFoU/+WYbaVQcANj6FHrONTKkyvrSax3VpMoB
wh0IDvlHvZJLtuGvP/68/jh5+OuP//Wbsby5bef3Fz99vLq/GDfzyeXow4eN
SbNb8Ifbjx86e2m2Ke389vr64ma8FohVueczkhgLJadgenv3cHV7M6KbI926
cBL0lKQ0lpDQS8fcRyB0w178eH4nUWoYDCrE8FkNzPcUEEsUjBhSHOlxCiqs
hCpLrRxdS0kpUaUJqBZ9usDDG3AJvIPwQib6yB4gZZqqQVFH/VEbcptV7+sT
a2TeNi/3JFIfKO3T+OUQ9gLZARbZJamgihXduCW/v//afp3J1jU0Ihe/zjI1
71S0WZVtZ2DFSVHAfi6m3VzSJIwvJJU6kgxlYeoxOOkRkO3eZLPTrfMv4T3c
9VDsI/cHZyQHNsB15A9yPhB9f/Ez2wqw9tVv1AaxW6SHMoYdumUqEYQb+4M8
NdGcJOTR8JimbaeQVA5BH4AdGgaPNu7z58/Uc25qy2QtnX2CzX6ruvtIC1Ci
xB2wmY7npFiwbjUIdtA2B11b2NZ2hrZoqdVjtJDjAUKoxUU3MtXrG3U6lHJU
rNZnwUwf1p78JYI3IC/9m4QQir+MJ/FDN511wZSkHWxp5HRsJxlIExz3jR2s
BeXMJEPln1EDSNjSVUwM7v5WxFbWoFV1SYkbgggpYiKnDxK+k2za7CANa4DQ
wEFMU6QCOJXaXq5oSnIuJTS7CY6op0j0kB0KWsDYNSFwVWGpAS8zlUBUG9gz
W4fql5jwj5Kg//coENPA/r622w/Rc2zTzfti5gU20fkNQv0NNkUduhDuY9Ne
MjEAm3z6BjLR6b18+ioy0ekX+QSLYg7jNEnvGjQQGZy/lVV3M2VTqjhT7vvd
4NN3vEGIqyinN7Z4AaMtQhmQkxXQyCmfVcBhhScb158DeaN/CxhUTuOFxjXi
AO/qpnT0RNP79OsKxrOINUiNKKhcfJr06ooW68w7qjO9/uZXQS9AOWoZ2IuU
3NhzN7ofXdfHmRnxsVNDvW7fxAs96BqB7Xcp7J4cYGv9OLiPj4NX9/cH8mFV
oiqbOdXojorfAsDOYXJyV3/xdT00HNw6atPJQpyTuC/2JXMdAi365ngn3Dde
/aL7FthsxrbijgMmV4+aYkArj06g+blhbm0q9t3QQQoXRC+/IGeqvkYM/xRA
/UVeWjQi04w7haU285iEW5uxQSV1o0U9fFja5skMbEdpjvcY+9Cip8GuSL9B
3dv8jgxUq4y1J5UZytXAlJ6U2RP3U7laxe6I8wGMwrpo70+RWeIPdVNFTxMb
2YiQDuyougPc3z3RG1ERItR5qSYnlMqHqBMVoNhh4ZlV0DvB67h1qhNVkbnU
8rZ5LrdOi82mNKKynYXJJsrCbNccIOAznr4A9+ri4V3949NQTHatVFNbhfoH
mK4b6dGlZrpWO8QJuvIqS1kzZFA8gsFElTaEbjHMTCDOI7b6fBbtcGYt4UwW
7EDHPzpMUZgodkbJI1DKdDqvH7FiTL+gpPICKGZgYF9eo3+Dve+rBGCpJYJ7
DEQvlcMN8O+1cnC5HFe0l0rKj7r4jwJv5HuVVo/sSoRLFRqedgJmKP4PQlWM
JugVAAA=
</rfc> </rfc>
 End of changes. 26 change blocks. 
411 lines changed or deleted 146 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/