rfc9364xml2.original.xml   rfc9364.xml 
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> <!DOCTYPE rfc [
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.6.17 (Ruby 2.
6.8) -->
<!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
]> ]>
<rfc ipr="trust200902" docName="draft-ietf-dnsop-dnssec-bcp-06" category="bcp" c <!-- generated by https://github.com/cabo/kramdown-rfc version 1.6.17 (Ruby 2.6.
onsensus="true" submissionType="IETF" tocDepth="4" tocInclude="true" sortRefs="t 8) -->
rue" symRefs="true">
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
-ietf-dnsop-dnssec-bcp-06" number="9364" submissionType="IETF" category="bcp" co
nsensus="true" tocDepth="4" tocInclude="true" sortRefs="true" symRefs="true" upd
ates="" obsoletes="" xml:lang="en" version="3">
<!-- xml2rfc v2v3 conversion 3.15.1 -->
<front> <front>
<title abbrev="DNSSEC">DNS Security Extensions (DNSSEC)</title> <title abbrev="DNSSEC">DNS Security Extensions (DNSSEC)</title>
<seriesInfo name="RFC" value="9364"/>
<seriesInfo name="BCP" value="237"/>
<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="2023" month="February"/>
<date year="2022" month="October" day="24"/> <area>ops</area>
<workgroup>dnsop</workgroup>
<keyword>Internet-Draft</keyword> <keyword>DNSSEC</keyword>
<keyword>DNS Security Extensions</keyword>
<keyword>DNS</keyword>
<abstract> <abstract>
<t>This document describes the DNS Security Extensions (commonly called "D
<t>This document describes the DNS security extensions (commonly called "DNSSEC" NSSEC") that are
) that are specified in RFCs 4033, 4034, and 4035, as well as a handful of others. One purp
specified RFCs 4033, 4034, 4035, and a handful of others. One purpose is to intr ose is to introduce
oduce
all of the RFCs in one place so that the reader can understand the many aspects of DNSSEC. 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. 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 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 t A third purpose is to provide a single reference for other documents that
o refer to DNSSEC.</t> want to refer to DNSSEC.</t>
<t>This document is currently maintained at https://github.com/paulehoffman/draf
t-hoffman-dnssec.
Issues and pull requests are welcomed.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="introduction">
<section anchor="introduction"><name>Introduction</name> <name>Introduction</name>
<t>The core specification for what we know as DNSSEC (the combination of <
<t>The core specification for what we know as DNSSEC (the combination of <xref t xref target="RFC4033"/>,
arget="RFC4033"/>,
<xref target="RFC4034"/>, and <xref target="RFC4035"/>) describes a set of proto cols that provide origin <xref target="RFC4034"/>, and <xref target="RFC4035"/>) describes a set of proto cols that provide origin
authentication of DNS data. <xref target="RFC6840"/> updates and extends those c ore RFCs, authentication of DNS data. <xref target="RFC6840"/> updates and extends those c ore RFCs
but does not fundamentally change the way that DNSSEC works.</t> but does not fundamentally change the way that DNSSEC works.</t>
<t>This document lists RFCs that should be considered by someone
<t>This document lists RFCs that should be considered by someone
creating an implementation of, or someone deploying, DNSSEC as it is currently s tandardized. creating an implementation of, or someone deploying, DNSSEC as it is currently s tandardized.
Although an effort was made to be thorough, the reader should not assume this li st is comprehensive. Although an effort was made to be thorough, the reader should not assume this li st is comprehensive.
It uses terminology from those documents without defining that terminology. It uses terminology from those documents without defining that terminology.
It also points to the relevant IANA registry groups that relate to DNSSEC. 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 It does not, however, point to standards that rely on zones needing to be signed
by DNSSEC by DNSSEC,
such as DANE <xref target="RFC6698"/>.</t> such as DNS-Based Authentication of Named Entities (DANE) <xref target="RFC6698"
/>.</t>
<section anchor="dnssec-as-a-best-current-practice"><name>DNSSEC as a Best Curre <section anchor="dnssec-as-a-best-current-practice">
nt Practice</name> <name>DNSSEC as a Best Current Practice</name>
<t>Using the DNSSEC set of protocols is the best current practice for ad
<t>Using the DNSSEC set of protocols is the best current practice for adding ding
origin authentication of DNS data. To date, no standards-track RFCs offer any ot origin authentication of DNS data. To date, no Standards Track RFCs offer any ot
her her
method for such origin authentication of data in the DNS.</t> method for such origin authentication of data in the DNS.</t>
<t>More than 15 years after the DNSSEC specification was published,
<t>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 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 r esolvers used for websites are signed, and only around a third of queries to recursive re solvers
are validated. However, this low level of deployment does not affect whether usi ng DNSSEC are validated. However, this low level of deployment does not affect whether usi ng DNSSEC
is a best current practice; it just indicates that the value of deploying DNSSEC is often is a best current practice; it just indicates that the value of deploying DNSSEC is often
considered lower than the cost. considered lower than the cost.
Nonetheless, the significant deployment of DNSSEC beneath some top-level domains Nonetheless, the significant deployment of DNSSEC beneath some top-level domains
(TLDs), (TLDs)
and the near-universal deployment of DNSSEC for the TLDs in the DNS root zone, 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 hi ghly sophisticated domain owners.</t> demonstrate that DNSSEC is applicable for implementation by both ordinary and hi ghly sophisticated domain owners.</t>
</section>
</section> <section anchor="implementing-dnssec">
<section anchor="implementing-dnssec"><name>Implementing DNSSEC</name> <name>Implementing DNSSEC</name>
<t>Developers of validating resolvers and authoritative servers,
<t>Developers of validating resolvers and authoritative servers,
as well as operators 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. 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 They should read the DNSSEC core documents and probably at least be familiar
with the extensions. with the extensions.
Developers will probably need to be very familiar with the algorithm documents a s well.</t> Developers will probably need to be very familiar with the algorithm documents a s well.</t>
<t>As a side note, some of the DNSSEC-related RFCs have significant erra
<t>As a side note, some of the DNSSEC-related RFCs have significant errata, so r ta, so reading the
eading the
RFCs should also include looking for the related errata.</t> RFCs should also include looking for the related errata.</t>
</section>
</section> </section>
</section> <section anchor="dnssec-core-documents">
<section anchor="dnssec-core-documents"><name>DNSSEC Core Documents</name> <name>DNSSEC Core Documents</name>
<t>What we refer to as "DNSSEC" is the third iteration of the DNSSEC speci
<t>What we refer to as "DNSSEC" is the third iteration of the DNSSEC specificati fication;
on;
<xref target="RFC2065"/> was the first, and <xref target="RFC2535"/> was the sec ond. <xref target="RFC2065"/> was the first, and <xref target="RFC2535"/> was the sec ond.
Earlier iterations have not been deployed on a significant scale. Earlier iterations have not been deployed on a significant scale.
Throughout this document, "DNSSEC" means the protocol initially defined in <xref target="RFC4033"/>, <xref target="RFC4034"/>, and <xref target="RFC4035"/>.</t > Throughout this document, "DNSSEC" means the protocol initially defined in <xref target="RFC4033"/>, <xref target="RFC4034"/>, and <xref target="RFC4035"/>.</t >
<t>The three initial core documents generally cover different topics:</t>
<t>The three initial core documents generally cover different topics:</t> <ul spacing="normal">
<li>
<t><list style="symbols"> <xref target="RFC4033"/> is an overview of DNSSEC, including how it mi
<t><xref target="RFC4033"/> is an overview of DNSSEC, including how it might c ght change the resolution of DNS queries.</li>
hange the resolution of DNS queries.</t> <li>
<t><xref target="RFC4034"/> specifies the DNS resource records used in DNSSEC. <xref target="RFC4034"/> specifies the DNS resource records used in DN
It obsoletes many RFCs for earlier versions of DNSSEC.</t> SSEC.
<t><xref target="RFC4035"/> covers the modifications to the DNS protocol incur It obsoletes many RFCs about earlier versions of DNSSEC.</li>
red by DNSSEC. <li>
<xref target="RFC4035"/> covers the modifications to the DNS protocol
incurred by DNSSEC.
These include signing zones, serving signed zones, resolving in light of These include signing zones, serving signed zones, resolving in light of
DNSSEC, and authenticating DNSSEC-signed data.</t> DNSSEC, and authenticating DNSSEC-signed data.</li>
</list></t> </ul>
<t>At the time this set of core documents was published, someone could cre
<t>At the time this set of core documents was published, someone could create a ate a DNSSEC
DNSSEC implementation of signing software, of a DNSSEC-aware authoritative server, and/
implementation of signing software, of an DNSSEC-aware authoritative server, and or of
/or
a DNSSEC-aware recursive resolver from the three core documents, plus a few olde r a DNSSEC-aware recursive resolver from the three core documents, plus a few olde r
RFCs specifying the cryptography used. Those two older documents are:</t> RFCs specifying the cryptography used. Those two older documents are the f
ollowing:</t>
<t><list style="symbols"> <ul spacing="normal">
<t><xref target="RFC2536"/> defines how to use the DSA signature algorithm (al <li>
though it refers to other <xref target="RFC2536"/> defines how to use the DSA signature algorith
m (although it refers to other
documents for the details). documents for the details).
DSA was thinly implemented and can safely be ignored by DNSSEC implementations.< DSA was thinly implemented and can safely be ignored by DNSSEC implementations.<
/t> /li>
<t><xref target="RFC3110"/> defines how to use the RSA signature algorithm (al <li>
though refers to other <xref target="RFC3110"/> defines how to use the RSA signature algorith
m (although refers to other
documents for the details). documents for the details).
RSA is still among the most popular signing algorithm for DNSSEC.</t> RSA is still among the most popular signing algorithms for DNSSEC.</li>
</list></t> </ul>
<t>It is important to note that later RFCs update the core documents. As j
<t>It is important to note that later RFCs update the core documents. As just on ust one example,
e example,
<xref target="RFC9077"/> changes how TTL values are calculated in DNSSEC process ing.</t> <xref target="RFC9077"/> changes how TTL values are calculated in DNSSEC process ing.</t>
<section anchor="addition-to-the-dnssec-core">
<section anchor="addition-to-the-dnssec-core"><name>Addition to the DNSSEC Core< <name>Addition to the DNSSEC Core</name>
/name> <t>As with any major protocol, developers and operators discovered issue
s with the original
<t>As with any major protocol, developers and operators discovered issues with t
he original
core documents over the years. core documents over the years.
<xref target="RFC6840"/> is an omnibus update to the original core documents and thus itself has <xref target="RFC6840"/> is an omnibus update to the original core documents and thus itself has
become a core document. become a core document.
In addition to covering new requirements from new DNSSEC RFCs, it describes many important 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 ini tial security and interoperability issues that arose during the deployment of the ini tial
specifications, particularly after the DNS root was signed in 2010. specifications, particularly after the DNS root was signed in 2010.
It also lists some errors in the examples of the core specifications.</t> It also lists some errors in the examples of the core specifications.</t>
<t><xref target="RFC6840"/> brings a few additions into the core of DNSS
<t><xref target="RFC6840"/> brings a few additions into the core of DNSSEC. EC.
It makes NSEC3 <xref target="RFC5155"/> as much a part of DNSSEC as NSEC is. It makes NSEC3 <xref target="RFC5155"/> as much a part of DNSSEC as NSEC
It also makes the SHA-2 hash function defined in <xref target="RFC4509"/> and <x is.
ref target="RFC5702"/> part of the core.</t> It also makes the SHA-256 and SHA-512 hash functions defined in <xref target="RF
C4509"/> and <xref target="RFC5702"/> part of the core.</t>
</section> </section>
</section> </section>
<section anchor="additional-cryptographic-algorithms-and-dnssec"><name>Additiona <section anchor="additional-cryptographic-algorithms-and-dnssec">
l Cryptographic Algorithms and DNSSEC</name> <name>Additional Cryptographic Algorithms and DNSSEC</name>
<t>Current cryptographic algorithms typically weaken over time as computin
<t>Current cryptographic algorithms typically weaken over time as computing powe g power improves and new cryptoanalysis emerges.
r improves and new cryptoanalysis emerges. Two new signing algorithms have been adopted by the DNSSEC community: Elliptic
Two new signing algorithms have been adopted by the DNSSEC community: ECDSA <xr Curve Digital Signature Algorithm (ECDSA) <xref target="RFC6605"/> and Edwards-c
ef target="RFC6605"/> and EdDSA <xref target="RFC8080"/>. urve Digital Signature Algorithm (EdDSA) <xref target="RFC8080"/>.
ECDSA and EdDSA have become very popular signing algorithms in recent years. ECDSA and EdDSA have become very popular signing algorithms in recent years.
The GOST signing algorithm <xref target="I-D.ietf-dnsop-rfc5933-bis"/> was also adopted, but has seen very limited use, likely The GOST signing algorithm <xref target="I-D.ietf-dnsop-rfc5933-bis"/> was also adopted but has seen very limited use, likely
because it is a national algorithm specific to a very small number of countries. </t> because it is a national algorithm specific to a very small number of countries. </t>
<t>Implementation developers who want to know which algorithms to implemen
<t>Implementation developers who want to know which algorithms to implement in D t in DNSSEC software
NSSEC software should refer to <xref target="RFC8624"/>.
should refer to <xref target="RFC8624"/>. Note that
Note that this specification is only about what algorithms should and should not this specification is only about what algorithms should and should
be included not be included in implementations, i.e., it is not advice about which
in implementations: it is not advice for which algorithms that zone operators sh algorithms zone operators should or should not use for signing, nor
ould and which algorithms recursive resolver operators should or should not use
should not sign with, nor which algorithms recursive resolver operators should o for validation.</t>
r should not </section>
be used for validation.</t> <section anchor="extensions-to-dnssec">
<name>Extensions to DNSSEC</name>
</section> <t>The DNSSEC community has extended the DNSSEC core and the cryptographic
<section anchor="extensions-to-dnssec"><name>Extensions to DNSSEC</name> algorithms, both
<t>The DNSSEC community has extended the DNSSEC core and the cryptographic algor
ithms both
in terms of describing good operational practices and in new protocols. Some of the in terms of describing good operational practices and in new protocols. Some of the
RFCs that describe these extensions include:</t> RFCs that describe these extensions include the following:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>
<t><xref target="RFC5011"/> describes a method to help resolvers update their <xref target="RFC5011"/> describes a method to help resolvers update t
DNSSEC trust anchors in an heir DNSSEC trust anchors in an
automated fashion. This method was used in 2018 to update the DNS root trust anc automated fashion. This method was used in 2018 to update the DNS root trust anc
hor.</t> hor.</li>
<t><xref target="RFC6781"/> is a compendium of operational practices that may <li>
not be obvious from reading <xref target="RFC6781"/> is a compendium of operational practices that
just the core specifications.</t> may not be obvious from reading
<t><xref target="RFC7344"/> describes using the CDS and CDNSKEY resource recor just the core specifications.</li>
ds to help automate the maintenance <li>
of DS records in the parents of signed zones.</t> <xref target="RFC7344"/> describes using the CDS and CDNSKEY resource
<t><xref target="RFC8078"/> extends <xref target="RFC7344"/> by showing how to records to help automate the maintenance
do initial setup of trusted relationships of DS records in the parents of signed zones.</li>
between signed parent and child zones.</t> <li>
<t><xref target="RFC8198"/> describes how a validating resolver can emit fewer <xref target="RFC8078"/> extends <xref target="RFC7344"/> by showing h
queries in signed zones that ow to do initial setup of trusted relationships
use NSEC and NSEC3 for negative caching.</t> between signed parent and child zones.</li>
<t><xref target="RFC9077"/> updates <xref target="RFC8198"/> with respect to t <li>
he time-to-live (TTL) fields in signed records.</t> <xref target="RFC8198"/> describes how a validating resolver can emit
</list></t> fewer queries in signed zones that
use NSEC and NSEC3 for negative caching.</li>
</section> <li>
<section anchor="additional-documents-of-interest"><name>Additional Documents of <xref target="RFC9077"/> updates <xref target="RFC8198"/> with respect
Interest</name> to the TTL fields in signed records.</li>
</ul>
<t>The documents listed above constitute the core of DNSSEC, the additional cryp </section>
tographic algorithms, <section anchor="additional-documents-of-interest">
<name>Additional Documents of Interest</name>
<t>The documents listed above constitute the core of DNSSEC, the additiona
l cryptographic algorithms,
and the major extensions to DNSSEC. and the major extensions to DNSSEC.
This section lists some additional documents that someone interested in implemen ting or operating This section lists some additional documents that someone interested in implemen ting or operating
DNSSEC might find of value.</t> DNSSEC might find of value:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>
<t><xref target="RFC4470"/> "describes how to construct DNSSEC NSEC resource r <xref target="RFC4470"/> "describes how to construct DNSSEC NSEC resou
ecords that cover a smaller range of rce records that cover a smaller range of
names than called for by <xref target="RFC4034"/>. By generating and signing the se records on demand, authoritative name names than called for by <xref target="RFC4034"/>. By generating and signing the se records on demand, authoritative name
servers can effectively stop the disclosure of zone contents otherwise made poss ible by walking the chain of NSEC records in a servers can effectively stop the disclosure of zone contents otherwise made poss ible by walking the chain of NSEC records in a
signed zone.".</t> signed zone".</li>
<t><xref target="RFC6975"/> "specifies a way for validating end-system resolve <li>
rs to signal to a server which digital signature <xref target="RFC6975"/> "specifies a way for validating end-system re
and hash algorithms they support".</t> solvers to signal to a server which digital signature
<t><xref target="RFC7129"/> "provides additional background commentary and som and hash algorithms they support".</li>
e context for the NSEC and NSEC3 <li>
<xref target="RFC7129"/> "provides additional background commentary an
d some context for the NSEC and NSEC3
mechanisms used by DNSSEC to provide authenticated denial-of-existence responses ". mechanisms used by DNSSEC to provide authenticated denial-of-existence responses ".
This background is particularly important for understanding NSEC and NSEC3 usage This background is particularly important for understanding NSEC and NSEC3 usage
.</t> .</li>
<t><xref target="RFC7583"/> "describes the issues surrounding the timing of ev <li>
ents in the rolling of a key in a DNSSEC-secured zone".</t> <xref target="RFC7583"/> "describes the issues surrounding the timing
<t><xref target="RFC7646"/> "defines Negative Trust Anchors (NTAs), which can of events in the rolling of a key in a DNSSEC-secured zone".</li>
be used to mitigate DNSSEC validation failures by disabling <li>
DNSSEC validation at specified domains".</t> <xref target="RFC7646"/> "defines Negative Trust Anchors (NTAs), which
<t><xref target="RFC7958"/> "describes the format and publication mechanisms I can be used to mitigate DNSSEC validation failures by disabling
ANA has used to distribute the DNSSEC trust anchors".</t> DNSSEC validation at specified domains".</li>
<t><xref target="RFC8027"/> "describes problems that a Validating DNS resolver <li>
, stub-resolver, or application might run into within <xref target="RFC7958"/> "describes the format and publication mechani
a non-compliant infrastructure".</t> sms IANA has used to distribute the DNSSEC trust anchors".</li>
<t><xref target="RFC8145"/> "specifies two different ways for validating resol <li>
vers to signal to a server which keys are <xref target="RFC8027"/> "describes problems that a Validating DNS res
referenced in their chain of trust".</t> olver, stub-resolver, or application might run into within
<t><xref target="RFC8499"/> is a list of terminology used when talking about t a non-compliant infrastructure".</li>
he DNS; sections 10 and 11 cover DNSSEC.</t> <li>
<t><xref target="RFC8509"/> "specifies a mechanism that will allow an end user <xref target="RFC8145"/> "specifies two different ways for validating
and third parties to determine the trusted key resolvers to signal to a server which keys are
state for the root key of the resolvers that handle that user's DNS queries".</t referenced in their chain of trust".</li>
> <li>
<t><xref target="RFC8901"/> "presents deployment models that accommodate this <xref target="RFC8499"/> contains lists of terminology used when talki
scenario [when each DNS ng about DNS; Sections <xref target="RFC8499" section="10" sectionFormat="bare"/
provider independently signs zone data with their own keys] and describes these > and <xref target="RFC8499" section="11" sectionFormat="bare"/> cover DNSSEC.</
key-management requirements".</t> li>
<t><xref target="RFC9276"/> "provides guidance on setting NSEC3 parameters bas <li>
ed on recent operational <xref target="RFC8509"/> "specifies a mechanism that will allow an end
deployment experience".</t> user and third parties to determine the trusted key
</list></t> state for the root key of the resolvers that handle that user's DNS queries".</l
i>
<t>There will certainly be other RFCs related to DNSSEC that are published after <li>
this one.</t> <xref target="RFC8901"/> "presents deployment models that accommodate
this scenario [when each DNS
</section> provider independently signs zone data with their own keys] and describes these
<section anchor="iana-considerations"><name>IANA Considerations</name> key-management requirements".</li>
<li>
<t>IANA already has three registry groups that relate to DNSSEC:</t> <xref target="RFC9276"/> "provides guidance on setting NSEC3 parameter
s based on recent operational
<t><list style="symbols"> deployment experience".</li>
<t><eref target="https://www.iana.org/assignments/dns-sec-alg-numbers">DNSSEC </ul>
algorithm numbers</eref></t> <t>There will certainly be other RFCs related to DNSSEC that are published
<t><eref target="https://www.iana.org/assignments/dnssec-nsec3-parameters">DNS after this one.</t>
SEC NSEC3 parameters</eref></t> </section>
<t><eref target="https://www.iana.org/assignments/ds-rr-types">DNSSEC DS RRtyp <section anchor="iana-considerations">
e digest algorithms</eref></t> <name>IANA Considerations</name>
</list></t> <t>IANA already has three registry groups that relate to DNSSEC:</t>
<ul spacing="normal">
<t>The rules for the DNSSEC algorithm registry were set in the core RFCs and <li>
<eref target="https://www.iana.org/assignments/dns-sec-alg-numbers">DN
SSEC algorithm numbers</eref></li>
<li>
<eref target="https://www.iana.org/assignments/dnssec-nsec3-parameters
">DNSSEC NSEC3 parameters</eref></li>
<li>
<eref target="https://www.iana.org/assignments/ds-rr-types">DNSSEC DS
RRtype digest algorithms</eref></li>
</ul>
<t>The rules for the DNSSEC algorithm registry were set in the core RFCs a
nd
updated by <xref target="RFC6014"/>, <xref target="RFC6725"/>, and <xref target= "RFC9157"/>.</t> updated by <xref target="RFC6014"/>, <xref target="RFC6725"/>, and <xref target= "RFC9157"/>.</t>
<t>This document does not update or create any registry groups or registri
<t>This document does not update or create any registry groups or registries.</t es.</t>
> </section>
<section anchor="security-considerations">
</section> <name>Security Considerations</name>
<section anchor="security-considerations"><name>Security Considerations</name> <t>All of the security considerations from all of the RFCs referenced in t
his document
<t>All of the security considerations from all of the RFCs referenced in this do
cument
apply here.</t> apply here.</t>
</section>
</section>
</middle> </middle>
<back> <back>
<references title='Normative References'> <displayreference target="I-D.ietf-dnsop-rfc5933-bis" to="GOST-SIGN"/>
<reference anchor='RFC3110' target='https://www.rfc-editor.org/info/rfc3110'>
<front>
<title>RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS)</title>
<author fullname='D. Eastlake 3rd' initials='D.' surname='Eastlake 3rd'><organiz
ation/></author>
<date month='May' year='2001'/>
<abstract><t>This document describes how to produce RSA/SHA1 SIG resource record
s (RRs) in Section 3 and, so as to completely replace RFC 2537, describes how to
produce RSA KEY RRs in Section 2. [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='3110'/>
<seriesInfo name='DOI' value='10.17487/RFC3110'/>
</reference>
<reference anchor='RFC4033' target='https://www.rfc-editor.org/info/rfc4033'>
<front>
<title>DNS Security Introduction and Requirements</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>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='RFC4509' target='https://www.rfc-editor.org/info/rfc4509'>
<front>
<title>Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs)</t
itle>
<author fullname='W. Hardaker' initials='W.' surname='Hardaker'><organization/><
/author>
<date month='May' year='2006'/>
<abstract><t>This document specifies how to use the SHA-256 digest type in DNS D
elegation Signer (DS) Resource Records (RRs). DS records, when stored in a pare
nt zone, point to DNSKEYs in a child zone. [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='4509'/>
<seriesInfo name='DOI' value='10.17487/RFC4509'/>
</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='RFC5702' target='https://www.rfc-editor.org/info/rfc5702'>
<front>
<title>Use of SHA-2 Algorithms with RSA in DNSKEY and RRSIG Resource Records for
DNSSEC</title>
<author fullname='J. Jansen' initials='J.' surname='Jansen'><organization/></aut
hor>
<date month='October' year='2009'/>
<abstract><t>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 Ext
ensions (RFC 4033, RFC 4034, and RFC 4035). [STANDARDS TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='5702'/>
<seriesInfo name='DOI' value='10.17487/RFC5702'/>
</reference>
<reference anchor='RFC6840' target='https://www.rfc-editor.org/info/rfc6840'>
<front>
<title>Clarifications and Implementation Notes for DNS Security (DNSSEC)</title>
<author fullname='S. Weiler' initials='S.' role='editor' surname='Weiler'><organ
ization/></author>
<author fullname='D. Blacka' initials='D.' role='editor' surname='Blacka'><organ
ization/></author>
<date month='February' year='2013'/>
<abstract><t>This document is a collection of technical clarifications to the DN
S Security (DNSSEC) document set. It is meant to serve as a resource to impleme
ntors as well as a collection of DNSSEC errata that existed at the time of writi
ng.</t><t>This document updates the core DNSSEC documents (RFC 4033, RFC 4034, a
nd RFC 4035) as well as the NSEC3 specification (RFC 5155). It also defines NSE
C3 and SHA-2 (RFC 4509 and RFC 5702) as core parts of the DNSSEC specification.<
/t></abstract>
</front>
<seriesInfo name='RFC' value='6840'/>
<seriesInfo name='DOI' value='10.17487/RFC6840'/>
</reference>
</references>
<references title='Informative References'>
<reference anchor='RFC2065' target='https://www.rfc-editor.org/info/rfc2065'>
<front>
<title>Domain Name System Security Extensions</title>
<author fullname='D. Eastlake 3rd' initials='D.' surname='Eastlake 3rd'><organiz
ation/></author>
<author fullname='C. Kaufman' initials='C.' surname='Kaufman'><organization/></a
uthor>
<date month='January' year='1997'/>
<abstract><t>The Domain Name System (DNS) has become a critical operational part
of the Internet infrastructure yet it has no strong security mechanisms to assu
re data integrity or authentication. Extensions to the DNS are described that p
rovide these services to security aware resolvers or applications through the us
e of cryptographic digital signatures. [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='2065'/>
<seriesInfo name='DOI' value='10.17487/RFC2065'/>
</reference>
<reference anchor='RFC2535' target='https://www.rfc-editor.org/info/rfc2535'>
<front>
<title>Domain Name System Security Extensions</title>
<author fullname='D. Eastlake 3rd' initials='D.' surname='Eastlake 3rd'><organiz
ation/></author>
<date month='March' year='1999'/>
<abstract><t>This document incorporates feedback on RFC 2065 from early implemen
ters and potential users. [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='2535'/>
<seriesInfo name='DOI' value='10.17487/RFC2535'/>
</reference>
<reference anchor='RFC2536' target='https://www.rfc-editor.org/info/rfc2536'>
<front>
<title>DSA KEYs and SIGs in the Domain Name System (DNS)</title>
<author fullname='D. Eastlake 3rd' initials='D.' surname='Eastlake 3rd'><organiz
ation/></author>
<date month='March' year='1999'/>
<abstract><t>A standard method for storing US Government Digital Signature Algor
ithm keys and signatures in the Domain Name System is described which utilizes D
NS KEY and SIG resource records. [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='2536'/>
<seriesInfo name='DOI' value='10.17487/RFC2536'/>
</reference>
<reference anchor='RFC4470' target='https://www.rfc-editor.org/info/rfc4470'>
<front>
<title>Minimally Covering NSEC Records and DNSSEC On-line Signing</title>
<author fullname='S. Weiler' initials='S.' surname='Weiler'><organization/></aut
hor>
<author fullname='J. Ihren' initials='J.' surname='Ihren'><organization/></autho
r>
<date month='April' year='2006'/>
<abstract><t>This document describes how to construct DNSSEC NSEC resource recor
ds that cover a smaller range of names than called for by RFC 4034. By generati
ng and signing these records on demand, authoritative name servers can effective
ly stop the disclosure of zone contents otherwise made possible by walking the c
hain of NSEC records in a signed zone. [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='4470'/>
<seriesInfo name='DOI' value='10.17487/RFC4470'/>
</reference>
<reference anchor='RFC5011' target='https://www.rfc-editor.org/info/rfc5011'>
<front>
<title>Automated Updates of DNS Security (DNSSEC) Trust Anchors</title>
<author fullname='M. StJohns' initials='M.' surname='StJohns'><organization/></a
uthor>
<date month='September' year='2007'/>
<abstract><t>This document describes a means for automated, authenticated, and a
uthorized updating of DNSSEC &quot;trust anchors&quot;. The method provides pro
tection 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 exis
ting anchor(s).</t><t>This mechanism will require changes to resolver management
behavior (but not resolver resolution behavior), and the addition of a single f
lag bit to the DNSKEY record. [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='STD' value='74'/>
<seriesInfo name='RFC' value='5011'/>
<seriesInfo name='DOI' value='10.17487/RFC5011'/>
</reference>
<reference anchor='I-D.ietf-dnsop-rfc5933-bis'>
<front>
<title>Use of GOST 2012 Signature Algorithms in DNSKEY and RRSIG Resource
Records for DNSSEC</title>
<author fullname='Dmitry Belyavsky' initials='D.' surname='Belyavsky'>
<organization>TCINET</organization>
</author>
<author fullname='Vasily Dolmatov' initials='V.' surname='Dolmatov'>
<organization>JSC &quot;NPK Kryptonite&quot;</organization>
</author>
<author fullname='Boris Makarenko' initials='B.' surname='Makarenko'>
<organization>The Technical center of Internet, LLC</organization>
</author>
<date day='23' month='October' year='2022'/>
<abstract>
<t> This document describes how to produce digital signatures and hash
functions using the GOST R 34.10-2012 and GOST R 34.11-2012
algorithms for DNSKEY, RRSIG, and DS resource records, for use in the
Domain Name System Security Extensions (DNSSEC).
This document obsoletes RFC 5933 and updates RFC 8624.
</t>
</abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-dnsop-rfc5933-bis-12'/>
<format target='https://www.ietf.org/archive/id/draft-ietf-dnsop-rfc5933-bis-
12.txt' type='TXT'/>
</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='RFC6605' target='https://www.rfc-editor.org/info/rfc6605'>
<front>
<title>Elliptic Curve Digital Signature Algorithm (DSA) for DNSSEC</title>
<author fullname='P. Hoffman' initials='P.' surname='Hoffman'><organization/></a
uthor>
<author fullname='W.C.A. Wijngaards' initials='W.C.A.' surname='Wijngaards'><org
anization/></author>
<date month='April' year='2012'/>
<abstract><t>This document describes how to specify Elliptic Curve Digital Signa
ture Algorithm (DSA) keys and signatures in DNS Security (DNSSEC). It lists cur
ves of different sizes and uses the SHA-2 family of hashes for signatures. [STA
NDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='6605'/>
<seriesInfo name='DOI' value='10.17487/RFC6605'/>
</reference>
<reference anchor='RFC6698' target='https://www.rfc-editor.org/info/rfc6698'>
<front>
<title>The DNS-Based Authentication of Named Entities (DANE) Transport Layer Sec
urity (TLS) Protocol: TLSA</title>
<author fullname='P. Hoffman' initials='P.' surname='Hoffman'><organization/></a
uthor>
<author fullname='J. Schlyter' initials='J.' surname='Schlyter'><organization/><
/author>
<date month='August' year='2012'/>
<abstract><t>Encrypted communication on the Internet often uses Transport Layer
Security (TLS), which depends on third parties to certify the keys used. This d
ocument improves on that situation by enabling the administrators of domain name
s to specify the keys used in that domain's TLS servers. This requires matching
improvements in TLS client software, but no change in TLS server software. [ST
ANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='6698'/>
<seriesInfo name='DOI' value='10.17487/RFC6698'/>
</reference>
<reference anchor='RFC6725' target='https://www.rfc-editor.org/info/rfc6725'>
<front>
<title>DNS Security (DNSSEC) DNSKEY Algorithm IANA Registry Updates</title>
<author fullname='S. Rose' initials='S.' surname='Rose'><organization/></author>
<date month='August' year='2012'/>
<abstract><t>The DNS Security Extensions (DNSSEC) require the use of cryptograph
ic algorithm suites for generating digital signatures over DNS data. The algorit
hms specified for use with DNSSEC are reflected in an IANA-maintained registry.
This document presents a set of changes for some entries of the registry. [STA
NDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='6725'/>
<seriesInfo name='DOI' value='10.17487/RFC6725'/>
</reference>
<reference anchor='RFC6781' target='https://www.rfc-editor.org/info/rfc6781'>
<front>
<title>DNSSEC Operational Practices, Version 2</title>
<author fullname='O. Kolkman' initials='O.' surname='Kolkman'><organization/></a
uthor>
<author fullname='W. Mekking' initials='W.' surname='Mekking'><organization/></a
uthor>
<author fullname='R. Gieben' initials='R.' surname='Gieben'><organization/></aut
hor>
<date month='December' year='2012'/>
<abstract><t>This document describes a set of practices for operating the DNS wi
th security extensions (DNSSEC). The target audience is zone administrators dep
loying DNSSEC.</t><t>The document discusses operational aspects of using keys an
d signatures in the DNS. It discusses issues of key generation, key storage, si
gnature generation, key rollover, and related policies.</t><t>This document obso
letes RFC 4641, as it covers more operational ground and gives more up-to-date r
equirements with respect to key sizes and the DNSSEC operations.</t></abstract>
</front>
<seriesInfo name='RFC' value='6781'/>
<seriesInfo name='DOI' value='10.17487/RFC6781'/>
</reference>
<reference anchor='RFC6975' target='https://www.rfc-editor.org/info/rfc6975'>
<front>
<title>Signaling Cryptographic Algorithm Understanding in DNS Security Extension
s (DNSSEC)</title>
<author fullname='S. Crocker' initials='S.' surname='Crocker'><organization/></a
uthor>
<author fullname='S. Rose' initials='S.' surname='Rose'><organization/></author>
<date month='July' year='2013'/>
<abstract><t>The DNS Security Extensions (DNSSEC) were developed to provide orig
in authentication and integrity protection for DNS data by using digital signatu
res. These digital signatures can be generated using different algorithms. Thi
s document specifies a way for validating end-system resolvers to signal to a se
rver which digital signature and hash algorithms they support. The extensions a
llow the signaling of new algorithm uptake in client code to allow zone administ
rators to know when it is possible to complete an algorithm rollover in a DNSSEC
-signed zone.</t></abstract>
</front>
<seriesInfo name='RFC' value='6975'/>
<seriesInfo name='DOI' value='10.17487/RFC6975'/>
</reference>
<reference anchor='RFC7129' target='https://www.rfc-editor.org/info/rfc7129'>
<front>
<title>Authenticated Denial of Existence in the DNS</title>
<author fullname='R. Gieben' initials='R.' surname='Gieben'><organization/></aut
hor>
<author fullname='W. Mekking' initials='W.' surname='Mekking'><organization/></a
uthor>
<date month='February' year='2014'/>
<abstract><t>Authenticated denial of existence allows a resolver to validate tha
t a certain domain name does not exist. It is also used to signal that a domain
name exists but does not have the specific resource record (RR) type you were a
sking for. When returning a negative DNS Security Extensions (DNSSEC) response,
a name server usually includes up to two NSEC records. With NSEC version 3 (NS
EC3), this amount is three.</t><t>This document provides additional background c
ommentary and some context for the NSEC and NSEC3 mechanisms used by DNSSEC to p
rovide authenticated denial-of-existence responses.</t></abstract>
</front>
<seriesInfo name='RFC' value='7129'/>
<seriesInfo name='DOI' value='10.17487/RFC7129'/>
</reference>
<reference anchor='RFC7344' target='https://www.rfc-editor.org/info/rfc7344'>
<front>
<title>Automating DNSSEC Delegation Trust Maintenance</title>
<author fullname='W. Kumari' initials='W.' surname='Kumari'><organization/></aut
hor>
<author fullname='O. Gudmundsson' initials='O.' surname='Gudmundsson'><organizat
ion/></author>
<author fullname='G. Barwood' initials='G.' surname='Barwood'><organization/></a
uthor>
<date month='September' year='2014'/>
<abstract><t>This document describes a method to allow DNS Operators to more eas
ily update DNSSEC Key Signing Keys using the DNS as a communication channel. Th
e technique described is aimed at delegations in which it is currently hard to m
ove information from the Child to Parent.</t></abstract>
</front>
<seriesInfo name='RFC' value='7344'/>
<seriesInfo name='DOI' value='10.17487/RFC7344'/>
</reference>
<reference anchor='RFC7583' target='https://www.rfc-editor.org/info/rfc7583'>
<front>
<title>DNSSEC Key Rollover Timing Considerations</title>
<author fullname='S. Morris' initials='S.' surname='Morris'><organization/></aut
hor>
<author fullname='J. Ihren' initials='J.' surname='Ihren'><organization/></autho
r>
<author fullname='J. Dickinson' initials='J.' surname='Dickinson'><organization/
></author>
<author fullname='W. Mekking' initials='W.' surname='Mekking'><organization/></a
uthor>
<date month='October' year='2015'/>
<abstract><t>This document describes the issues surrounding the timing of events
in the rolling of a key in a DNSSEC-secured zone. It presents timelines for th
e key rollover and explicitly identifies the relationships between the various p
arameters affecting the process.</t></abstract>
</front>
<seriesInfo name='RFC' value='7583'/>
<seriesInfo name='DOI' value='10.17487/RFC7583'/>
</reference>
<reference anchor='RFC7646' target='https://www.rfc-editor.org/info/rfc7646'>
<front>
<title>Definition and Use of DNSSEC Negative Trust Anchors</title>
<author fullname='P. Ebersman' initials='P.' surname='Ebersman'><organization/><
/author>
<author fullname='W. Kumari' initials='W.' surname='Kumari'><organization/></aut
hor>
<author fullname='C. Griffiths' initials='C.' surname='Griffiths'><organization/
></author>
<author fullname='J. Livingood' initials='J.' surname='Livingood'><organization/
></author>
<author fullname='R. Weber' initials='R.' surname='Weber'><organization/></autho
r>
<date month='September' year='2015'/>
<abstract><t>DNS Security Extensions (DNSSEC) is now entering widespread deploym
ent. However, domain signing tools and processes are not yet as mature and reli
able as those for non-DNSSEC-related domain administration tools and processes.
This document defines Negative Trust Anchors (NTAs), which can be used to mitig
ate DNSSEC validation failures by disabling DNSSEC validation at specified domai
ns.</t></abstract>
</front>
<seriesInfo name='RFC' value='7646'/>
<seriesInfo name='DOI' value='10.17487/RFC7646'/>
</reference>
<reference anchor='RFC7958' target='https://www.rfc-editor.org/info/rfc7958'>
<front>
<title>DNSSEC Trust Anchor Publication for the Root Zone</title>
<author fullname='J. Abley' initials='J.' surname='Abley'><organization/></autho
r>
<author fullname='J. Schlyter' initials='J.' surname='Schlyter'><organization/><
/author>
<author fullname='G. Bailey' initials='G.' surname='Bailey'><organization/></aut
hor>
<author fullname='P. Hoffman' initials='P.' surname='Hoffman'><organization/></a
uthor>
<date month='August' year='2016'/>
<abstract><t>The root zone of the Domain Name System (DNS) has been cryptographi
cally signed using DNS Security Extensions (DNSSEC).</t><t>In order to obtain se
cure answers from the root zone of the DNS using DNSSEC, a client must configure
a suitable trust anchor. This document describes the format and publication me
chanisms IANA has used to distribute the DNSSEC trust anchors.</t></abstract>
</front>
<seriesInfo name='RFC' value='7958'/>
<seriesInfo name='DOI' value='10.17487/RFC7958'/>
</reference>
<reference anchor='RFC8027' target='https://www.rfc-editor.org/info/rfc8027'>
<front>
<title>DNSSEC Roadblock Avoidance</title>
<author fullname='W. Hardaker' initials='W.' surname='Hardaker'><organization/><
/author>
<author fullname='O. Gudmundsson' initials='O.' surname='Gudmundsson'><organizat
ion/></author>
<author fullname='S. Krishnaswamy' initials='S.' surname='Krishnaswamy'><organiz
ation/></author>
<date month='November' year='2016'/>
<abstract><t>This document describes problems that a Validating DNS resolver, st
ub-resolver, or application might run into within a non-compliant infrastructure
. It outlines potential detection and mitigation techniques. The scope of the
document is to create a shared approach to detect and overcome network issues th
at a DNSSEC software/system may face.</t></abstract>
</front>
<seriesInfo name='BCP' value='207'/>
<seriesInfo name='RFC' value='8027'/>
<seriesInfo name='DOI' value='10.17487/RFC8027'/>
</reference>
<reference anchor='RFC8078' target='https://www.rfc-editor.org/info/rfc8078'>
<front>
<title>Managing DS Records from the Parent via CDS/CDNSKEY</title>
<author fullname='O. Gudmundsson' initials='O.' surname='Gudmundsson'><organizat
ion/></author>
<author fullname='P. Wouters' initials='P.' surname='Wouters'><organization/></a
uthor>
<date month='March' year='2017'/>
<abstract><t>RFC 7344 specifies how DNS trust can be maintained across key rollo
vers in-band between parent and child. This document elevates RFC 7344 from Inf
ormational to Standards Track. It also adds a method for initial trust setup an
d removal of a secure entry point.</t><t>Changing a domain's DNSSEC status can b
e a complicated matter involving multiple unrelated parties. Some of these part
ies, 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 pr
oblem or liability that prevents some DNSSEC adoption at a large scale. This do
cument adds a method for in-band signaling of these DNSSEC status changes.</t><t
>This document describes reasonable policies to ease deployment of the initial a
cceptance of new secure entry points (DS records).</t><t>It is preferable that o
perators 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 th
is 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 preferr
ed over the alternative of validation failures due to a mismatched DS and DNSKEY
record.</t></abstract>
</front>
<seriesInfo name='RFC' value='8078'/>
<seriesInfo name='DOI' value='10.17487/RFC8078'/>
</reference>
<reference anchor='RFC8080' target='https://www.rfc-editor.org/info/rfc8080'>
<front>
<title>Edwards-Curve Digital Security Algorithm (EdDSA) for DNSSEC</title>
<author fullname='O. Sury' initials='O.' surname='Sury'><organization/></author>
<author fullname='R. Edmonds' initials='R.' surname='Edmonds'><organization/></a
uthor>
<date month='February' year='2017'/>
<abstract><t>This document describes how to specify Edwards-curve Digital Securi
ty Algorithm (EdDSA) keys and signatures in DNS Security (DNSSEC). It uses EdDS
A with the choice of two curves: Ed25519 and Ed448.</t></abstract>
</front>
<seriesInfo name='RFC' value='8080'/>
<seriesInfo name='DOI' value='10.17487/RFC8080'/>
</reference>
<reference anchor='RFC8145' target='https://www.rfc-editor.org/info/rfc8145'>
<front>
<title>Signaling Trust Anchor Knowledge in DNS Security Extensions (DNSSEC)</tit
le>
<author fullname='D. Wessels' initials='D.' surname='Wessels'><organization/></a
uthor>
<author fullname='W. Kumari' initials='W.' surname='Kumari'><organization/></aut
hor>
<author fullname='P. Hoffman' initials='P.' surname='Hoffman'><organization/></a
uthor>
<date month='April' year='2017'/>
<abstract><t>The DNS Security Extensions (DNSSEC) were developed to provide orig
in authentication and integrity protection for DNS data by using digital signatu
res. These digital signatures can be verified by building a chain of trust star
ting from a trust anchor and proceeding down to a particular node in the DNS. T
his document specifies two different ways for validating resolvers to signal to
a server which keys are referenced in their chain of trust. The data from such
signaling allow zone administrators to monitor the progress of rollovers in a DN
SSEC-signed zone.</t></abstract>
</front>
<seriesInfo name='RFC' value='8145'/>
<seriesInfo name='DOI' value='10.17487/RFC8145'/>
</reference>
<reference anchor='RFC8198' target='https://www.rfc-editor.org/info/rfc8198'>
<front>
<title>Aggressive Use of DNSSEC-Validated Cache</title>
<author fullname='K. Fujiwara' initials='K.' surname='Fujiwara'><organization/><
/author>
<author fullname='A. Kato' initials='A.' surname='Kato'><organization/></author>
<author fullname='W. Kumari' initials='W.' surname='Kumari'><organization/></aut
hor>
<date month='July' year='2017'/>
<abstract><t>The DNS relies upon caching to scale; however, the cache lookup gen
erally requires an exact match. This document specifies the use of NSEC/NSEC3 r
esource records to allow DNSSEC-validating resolvers to generate negative answer
s within a range and positive answers from wildcards. This increases performanc
e, decreases latency, decreases resource utilization on both authoritative and r
ecursive servers, and increases privacy. Also, it may help increase resilience
to certain DoS attacks in some circumstances.</t><t>This document updates RFC 40
35 by allowing validating resolvers to generate negative answers based upon NSEC
/NSEC3 records and positive answers in the presence of wildcards.</t></abstract>
</front>
<seriesInfo name='RFC' value='8198'/>
<seriesInfo name='DOI' value='10.17487/RFC8198'/>
</reference>
<reference anchor='RFC8499' target='https://www.rfc-editor.org/info/rfc8499'>
<front>
<title>DNS Terminology</title>
<author fullname='P. Hoffman' initials='P.' surname='Hoffman'><organization/></a
uthor>
<author fullname='A. Sullivan' initials='A.' surname='Sullivan'><organization/><
/author>
<author fullname='K. Fujiwara' initials='K.' surname='Fujiwara'><organization/><
/author>
<date month='January' year='2019'/>
<abstract><t>The Domain Name System (DNS) is defined in literally dozens of diff
erent RFCs. The terminology used by implementers and developers of DNS protocol
s, and by operators of DNS systems, has sometimes changed in the decades since t
he DNS was first defined. This document gives current definitions for many of t
he terms used in the DNS in a single document.</t><t>This document obsoletes RFC
7719 and updates RFC 2308.</t></abstract>
</front>
<seriesInfo name='BCP' value='219'/>
<seriesInfo name='RFC' value='8499'/>
<seriesInfo name='DOI' value='10.17487/RFC8499'/>
</reference>
<reference anchor='RFC8509' target='https://www.rfc-editor.org/info/rfc8509'>
<front>
<title>A Root Key Trust Anchor Sentinel for DNSSEC</title>
<author fullname='G. Huston' initials='G.' surname='Huston'><organization/></aut
hor>
<author fullname='J. Damas' initials='J.' surname='Damas'><organization/></autho
r>
<author fullname='W. Kumari' initials='W.' surname='Kumari'><organization/></aut
hor>
<date month='December' year='2018'/>
<abstract><t>The DNS Security Extensions (DNSSEC) were developed to provide orig
in authentication and integrity protection for DNS data by using digital signatu
res. These digital signatures can be verified by building a chain of trust star
ting from a trust anchor and proceeding down to a particular node in the DNS. T
his document 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 handl
e that user's DNS queries. Note that this method is only applicable for determi
ning which keys are in the trust store for the root key.</t></abstract>
</front>
<seriesInfo name='RFC' value='8509'/>
<seriesInfo name='DOI' value='10.17487/RFC8509'/>
</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>
<reference anchor='RFC8901' target='https://www.rfc-editor.org/info/rfc8901'>
<front>
<title>Multi-Signer DNSSEC Models</title>
<author fullname='S. Huque' initials='S.' surname='Huque'><organization/></autho
r>
<author fullname='P. Aras' initials='P.' surname='Aras'><organization/></author>
<author fullname='J. Dickinson' initials='J.' surname='Dickinson'><organization/
></author>
<author fullname='J. Vcelak' initials='J.' surname='Vcelak'><organization/></aut
hor>
<author fullname='D. Blacka' initials='D.' surname='Blacka'><organization/></aut
hor>
<date month='September' year='2020'/>
<abstract><t>Many enterprises today employ the service of multiple DNS providers
to distribute their authoritative DNS service. Deploying DNSSEC in such an envi
ronment may present some challenges, depending on the configuration and feature
set in use. In particular, when each DNS provider independently signs zone data
with their own keys, additional key-management mechanisms are necessary. This do
cument presents deployment models that accommodate this scenario and describes t
hese key-management requirements. These models do not require any changes to the
behavior of validating resolvers, nor do they impose the new key-management req
uirements on authoritative servers not involved in multi-signer configurations.<
/t></abstract>
</front>
<seriesInfo name='RFC' value='8901'/>
<seriesInfo name='DOI' value='10.17487/RFC8901'/>
</reference>
<reference anchor='RFC9077' target='https://www.rfc-editor.org/info/rfc9077'>
<front>
<title>NSEC and NSEC3: TTLs and Aggressive Use</title>
<author fullname='P. van Dijk' initials='P.' surname='van Dijk'><organization/><
/author>
<date month='July' year='2021'/>
<abstract><t>Due to a combination of unfortunate wording in earlier documents, a
ggressive use of NSEC and NSEC3 records may deny the existence of names far beyo
nd the intended lifetime of a denial. This document changes the definition of th
e NSEC and NSEC3 TTL to correct that situation. This document updates RFCs 4034,
4035, 5155, and 8198.</t></abstract>
</front>
<seriesInfo name='RFC' value='9077'/>
<seriesInfo name='DOI' value='10.17487/RFC9077'/>
</reference>
<reference anchor='RFC9157' target='https://www.rfc-editor.org/info/rfc9157'> <references>
<front> <name>References</name>
<title>Revised IANA Considerations for DNSSEC</title> <references>
<author fullname='P. Hoffman' initials='P.' surname='Hoffman'><organization/></a <name>Normative References</name>
uthor> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
<date month='December' year='2021'/> 110.xml"/>
<abstract><t>This document changes the review requirements needed to get DNSSEC <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
algorithms and resource records added to IANA registries. It updates RFC 6014 to 033.xml"/>
include hash algorithms for Delegation Signer (DS) records and NextSECure versi <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
on 3 (NSEC3) parameters (for Hashed Authenticated Denial of Existence). It also 034.xml"/>
updates RFCs 5155 and 6014, which have requirements for DNSSEC algorithms, and u <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
pdates RFC 8624 to clarify the implementation recommendation related to the algo 035.xml"/>
rithms described in RFCs that are not on the standards track. The rationale for <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
these changes is to bring the requirements for DS records and hash algorithms us 509.xml"/>
ed in NSEC3 in line with the requirements for all other DNSSEC algorithms.</t></ <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
abstract> 155.xml"/>
</front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
<seriesInfo name='RFC' value='9157'/> 702.xml"/>
<seriesInfo name='DOI' value='10.17487/RFC9157'/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
</reference> 840.xml"/>
</references>
<references>
<name>Informative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
065.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
535.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
536.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
470.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
011.xml"/>
<reference anchor='RFC9276' target='https://www.rfc-editor.org/info/rfc9276'> <reference anchor="I-D.ietf-dnsop-rfc5933-bis">
<front> <front>
<title>Guidance for NSEC3 Parameter Settings</title> <title>Use of GOST 2012 Signature Algorithms in DNSKEY and RRSIG Resource Record
<author fullname='W. Hardaker' initials='W.' surname='Hardaker'><organization/>< s for DNSSEC
/author> </title>
<author fullname='V. Dukhovni' initials='V.' surname='Dukhovni'><organization/>< <author initials="D." surname="Belyavsky" fullname="Dmitry Belyavsky">
/author> <organization>TCINET</organization>
<date month='August' year='2022'/> </author>
<abstract><t>NSEC3 is a DNSSEC mechanism providing proof of nonexistence by asse <author initials="V." surname="Dolmatov" fullname="Vasily Dolmatov" role="editor
rting that there are no names that exist between two domain names within a zone. ">
Unlike its counterpart NSEC, NSEC3 avoids directly disclosing the bounding dom <organization>JSC "NPK Kryptonite"</organization>
ain name pairs. This document provides guidance on setting NSEC3 parameters bas </author>
ed on recent operational deployment experience. This document updates RFC 5155 <author initials="B." surname="Makarenko" fullname="Boris Makarenko" role="edito
with guidance about selecting NSEC3 iteration and salt parameters.</t></abstract r">
> <organization>The Technical center of Internet, LLC</organization>
</author>
<date month="November" day="30" year="2022"/>
</front> </front>
<seriesInfo name='BCP' value='236'/> <seriesInfo name="Internet-Draft" value="draft-ietf-dnsop-rfc5933-bis-13"/>
<seriesInfo name='RFC' value='9276'/>
<seriesInfo name='DOI' value='10.17487/RFC9276'/>
</reference> </reference>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
014.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
605.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
698.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
725.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
781.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
975.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
129.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
344.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
583.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
646.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
958.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
027.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
078.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
080.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
145.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
198.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
499.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
509.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
624.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
901.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
077.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
157.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
276.xml"/>
</references>
</references> </references>
<section anchor="acknowledgements" numbered="false">
<section anchor="acknowledgements"><name>Acknowledgements</name> <name>Acknowledgements</name>
<t>The DNS world owes a depth of gratitude to the authors and other contri
<t>The DNS world owes a depth of gratitude to the authors and other contributors butors
to the core DNSSEC documents, and to the notable DNSSEC extensions.</t> to the core DNSSEC documents and to the notable DNSSEC extensions.</t>
<t>In addition, the following people made significant contributions to ear
<t>In addition, the following people made significant contributions to early ver ly draft versions
sions of this document: <contact fullname="Ben Schwartz"/> and <contact fullname="Duan
of this document: Ben Schwartz and Duane Wessels.</t> e Wessels"/>.</t>
</section>
</section>
</back> </back>
<!-- ##markdown-source:
H4sIALCsVmMAA51aa5PbOHb9zl/B8lQqdpUkq9+P+ZIe25vtyqZ3yt3JVmp3
KwWRkIRtkmAIsmXNlP97zrkASEht707yYTwUGwQu7uPccy8wn8+z3vSVvs0/
Pjzmj7oYOtPv809fet04YxuXv8UfHj99eJep1arTLzIQv7PSFo2q8WHZqXU/
N7pfz8vG2Zb/Ol3MV0U7X15mmetVU/63qmyDwX036AyTnGWZaTv57frT5fJm
eZo9727z+6bXXaP7+UfOmhWqv80xUVZAFEg0uDCFG1a1cZTwad9i3vtPT7/L
stbcZnne2+I232vnH0vd9tvb/By/nO36Tq9d/Kvb19PPTA391naYYI4/5abB
+58X+e/tel2rhq/8dn9WQ5W+td0Gy3+4e3jgL10rU93mLQYttn7Qv5hCNc0C
47KssV2tevOiKefn3304OzlZhsfz5dnZ9Hg+PV7Ex4vlTXi8OLmIby+ulqfh
8fL6HJNlplkfrXK6vIzDTy/OksfLOPX5VRTjYnlywsf7+cdFYtNuXVzcnJ3N
V8bF1ZYnUcjLy+XF+HhzHR+vTse3V9cn8fHmKr69OjmNG7o6O4+TXV1cRz1c
XZ5HCa9uLuK818vTq/Hxanp7HbdwfXJ+MT6O4lyf38TVridNXl+exoWvb5ZR
yJvlVVzi5uRifDy9gjjZfD7P1cr1nSr6LHvaGpcjFoZaN31eald0ZqVd3m+1
hJSLIaWTkCpsXdum2ueFqipd5m98TL15h89Un6sODt7qwqwN/oiVXU7vmPHf
c/n3YpYjqHKVb/G/NRzSrnOLJTu3yP/Y6LwdutY6nUO23sKX+86WQ6EzLMeh
FE6mNU1uObxShUZ4+OX5106rUneQr8mHBk8SxPIXePQ+VxSvd5zLi744VoSF
Dhrb50Nbql7n/EgWplRcepHdUTcWsx4Ki5UwXgQZnGk2YYEcTo1YMxuIzEjF
IoirHvoMQuRYR8kcEBIW6HMovqMsLS1lCs0l+63pjldsO/tiSsiYc72Km19r
fAmVyKLU67gz50XbKUyMb2UoH6IajvSA5yAGrA1saHr8B6Niim3ft+72/fuN
6bfDagGfeE/Y0AE23ntcDb8CqC6ye+cGqFaJ3mDNTv8PfkMsOE2+0xWm0eXC
e2ltyrLSWfYDYVU8gPqiiDovLMYHJwt65GZ3sjmdPzd2BytH5b/t5ZN6ZZpR
57/+GlDr69dZFn+c44cIF19cfP36LgkL6Fj3/BpKBzjbKugz2sBbOPu+hRd+
ZmLd16/Bu7w6JMBKF3xM9kdHm2WrIfHHNdxZ0TQIBcQf4mejxWV2au9FCVve
2e7ZvbJnZahriR0Z7LZ2qEr4W84MhR10MO5qj1iqNSIrKxBIPb0YgWTqttKy
dNjUDNuNI6GjtrJ7DJ1FCaB+c+RBEoaqK80vNPJdhb0Omy0n12uYj37p4GZQ
JFxyxY3ZjiNmaVAHmakNBW+qOQyrcGuymq3bTm8JVi+ImXvGIQFNd7VpbGU3
+3zd2TroeYqLnaE0xMC1abhlDybTZzKXqgAzrTUSSTaIVekXxtP93cMdfm0g
SLfPN5C8DWrGEEGFKc7uJ5vO8q3d6RfdzfzEAUVEUdP3wJ8m/wWaxjdalyKg
6MiZTeONFpiNG4qt+P7dw6fgbchqX7/CGX74ITGOyn8izHwIMPNzgJks+w/n
t6/j4Fc+//dgSuJQlZQw+4eAt8ifLB/0DJqYdj1ndnr2fgoAgdEFgIlkWa1h
p1JWkZ1+dw0PqE3cCLb/7wwqKLTJTy5AmlQHJax7AmCy1wNMoT+2wwq+tdXl
LPP+7HoD5KL/7RAxsIz3fbh0/lkX1AX0Ymof2V1IBmu9k4W4+PKfYhYrLUFV
qJnL4Kd+Xzu9glnj597AHpYk6yp4lmRPnw0wFTC0M9p5RIdB6Pp4craCW7mM
s7yoylDRJTlhcDcfN0BKOLCWzOp3cpgCFQxQYK9bLZkkzWqZoRt90w1+ZPD/
bWBMNiXVqd2UniHMoKf1kjRpaHAAYZbgESSMqvM47vpF9oBQwK9KO+fRgWoS
wwmPGbcxpniI2QDMtoJY0FQ797v2JgCrefrDR/dulkWigMHdfGgMNaiqb09J
Y3EsP01cLe8s9MZgnWWlBlUi24qsYNqoatsK8q4qHzNH+IqAXsHj4d8IJQVA
oWBbs9kSR20L04mzQz/BieyuIYGSKL+PcyW2yj5yv7bFIG4hOAQHjJ7iWZkU
EqYXCo7Y7/gX6MUxP1dEDs6hevv/m4foRUeVFE2FtarzVCyJwgg1ga0I4Ac/
xKiadE3vYyZgXkg/ltw5ArsPHEy4gqb3ZC6VVnBLQOda1aYyqsuI/TLDxHIX
qbp2DPhxirgDzIAt7cdp8nEaVW24822d5JegP9jnTngE6QLCC8gnDnmw/7lP
GIE8b9XLoXvrDupX/FD2HtA6k8FBJ5KnTFNUA5aprH3moOiucXY/DyTKxrzw
gbr7GIXOsj8FQjUSRWwj0v2YBjwMAa+6EXu/B6g/eqbFig70h+jKkWsDgp7w
LlZ5yZ89z15kn1RXGUgxrhRUQ5Baad2MOMxUqQ405lCpaHqN0Amm+T7lRbNp
T7VWjV929EHQgd4I3xJugPkRbSl9zF/Rx5Q/Ljxj7bed1nGuIx/NN8CmzlM6
+0K6btbC4UkGWlM41m3pkgIf0DTGvhi9myBpFoxOc4NWEIRrYEafUkUJ0yFN
xSF/LNJVsJdou6Qe5LdDV3ASbAH8RJIW9JEQG7vC/JqAL8WWuCVdTwf7EQfE
ekn5lSxM04sW/Kq1LUf3GTkXRUnsI8kn4UCCDyyQQgCIK0Ajwp9mgkX8GahT
eOvRi++xnUqUZtdZVGtEtMgxRlydh1lKH0p3PsMh/wdeGsjTkcEPicXIogsJ
XmHdLOhilj1m3uOGHJLlDul9xpcqWmGu+O6bACwbeW+7TB2OfU0bIkuOnnuM
qm01EMfW9L4KiTrAj3jMPhLIotu3vd10qt3uxVVA+IR39zvrP0sRstOTn7O9
A0fwEefEl2H7wXkX/vh4JzpQ/dClcPtWxZrC9B6zxGU8c5xWikBYatSzlXsH
sMeEHm8MKdaocda6sDwbCU6tSfaA+ljYHvjbUe5OAokdsu9v4/M/3Mb/ZQ+c
baSnCrRjEwII2a61KLeRoqLjTGtxnjEK74XgYjcoxkKLgDnKp2Emjc6Hc2iL
9Ntjv1jkyG5C++jO+ouiYkJ9zbYUY1uQyOvi6ekPngx6qguULgafm0ZIYZwX
YHmQ2nObO9QWEgcTFsTMJblVsjCBp1Z/w94iTMygqTGhC5ceWUxpnAAOl/X9
iTGT++pCVdlR/ApKc4CUEYssreoDNteNWQ2TquzBfMd44FnnwJLZ6WqNxOay
lWY3BDF2MBYQ20h9FXUgotOmDUKR/RTT6eAijGC+DSqSfgIjY2poCEKP9s7G
dh/lMWxmi5ZW4Dd4GZQTmnxSPg9dDPVDgsw3IddlBwyAyAHCZ2jnjnwsLcA8
cWYcBlCFF5wuT5ZT6e0bGMKYwF5ovEC7g6uNRPJ1g4hRmZppRdEjhEWFcr5g
KpkhSVEQoVbPWOEBP898eLOTjanYtZCqW/aWFAjKj4bmpi34SbjC4+/v5qc0
9ZZ9HeluvaYYF8sbrhC5ERvm+B3XiYIyNMbIgHt9mIDXFPldjHbvaLEgiKV/
cTBYTYP7PciH0JKdhtRNcHvmNuU7LYNkwlYqNLhRhwF+Dbqdn1dBnr1DUMAr
uw1ZxhPAn39/jUaB0QmbU6Vte4+yB+S+rlGV9fvb/NMHonbocCwvgpY+leNb
NtXJv/zA6Y9hDYkuYfDfRUdxr84X9SHSyeX+9Y+PT9+A0l9//f6xQ+Cz4gFh
Z7Ocrb0tvZ37FUkqUxtuGhlihh/PyDjEAcWM4bsPKvc9TBh5Wjk6ujB0P5Or
2S1vhnoF0wgBGZo+sLz7Q0KRAONua8fmsFRoO7jE9sAn7JTtEpSOTCQbi7JQ
MHhLXJ6e0xIPYzLx3Oig2cLaX/obKxJ0aeUm68bCBlZMOoCrkeSVmTnuUbrb
oDNpY5QvsTv1ek9cizQwSQrTelmyHo0u2YENq2/M9A0e9WpKm/YwYd18bPzE
Wto2vihLzjHH3qGvJo6jQdzIt5D162I49jS+G+jsNFB/bHc635iRDEH/3lgb
k6V3u9jicSFLSCyPzcFF/jjVs9nUao45h69dWmlHA07cj4d4Qpqmtnvo+kEL
W121SadhYiIm8hh/Kgvhim1IEEpa8rYWZrEG3lLDubTGw8SMzVjKIONcC0ub
SM6Ym9KpJ5bHA8KQ+AUVYQUz1HKq9U29iUJqtY8ubFcvxg4hYYeSPhMW9f1U
Fpbm0eOBroaxewvUEwt9gPT/9um/XtduUZtRN+GAjHm/wRZ1xkT2OA4PmRap
x1Og9UEBNYnEY02IFA80UjFX0rTZxeoUApR2rIlRKQ2tOA6VrEvfp+B2t6Yl
Hep3xMmwqBfDs/OtqV5LccKmd6IYLqi+1a4Sdq+Bu6FJG7uppjnYoFiNTVqf
0rmwZwKM3EZvfJlVKEgjVDXIEVhvPOpJZROWCSla6WvZsXCc93ZecbK34Mfv
chTgVZmKEwziMSJJ+h8nerr2VxG06z1eTEyTDIpVzcq++FOf3vRDyuWTXoL0
sqb5vwcfU9PUU279DdgKJ6wgmIL1CY9LFjg6pYxVsQlb8eFp0t6mjfjKiAnh
7xseoFFl6E8OOmkwnF+R/L059Auh0WzTDsXYoRUrv44ZCuabNMrnWDx10lux
60wa+b5VHc7G6Rzw+qSrssh/2oeGTzhaK0cu4bExriWpGQydzf+DWp7LZKGj
6r1XeqP4kxyy2dYzcpQ1lXWDt+kvvr/A2KaDsJrcGaf9cVtrUWCxEQ1Rd6p6
Huv3rXSW11EZIxCoLAmNxZsECm+uyMTeTK0jJWeTaXrD5ECGudvDpHWC5Tz4
YjVceRrjNxhybIm6qSdIxHJZfE6480EiZ1t4aFnPJELxqgaFCse0LvW5lSqe
N/5EhdmU3CE028U7RWNf+rHcPoz9rNYsZ42rQ/qYWgLpyfzUN2KjSDdAu7ld
z/UXxmIj3uVaXhFyb0KcJFLh10HFNFXnlGm63kC1HiHT4NQm8X3eTTn0fSnT
fFUHP5H1oukBRBJg6xzskC4T4L+zVRX+oPJnqJveMPbCSH+CV6T6vzy/9Av7
NshDRMsnSad3IVO/fXi6c+9mweL060iOoEzgs9kwSQX9TlwJGd1UWNZR+3B6
taoSNEjGEVLGeynh3CeV8ubi+rV6/G2kcGNhVUWymhhezn23kUAwp/EEGMX/
RB5esZI3abo8vTpclicNgLhYaef/OcVN7MFW0stz/bCaTz958OrPlLyIgoPd
0PialtmGdxNAOpo5WUpllFD4dac88kGHqVwn50eRzKbd1JlGVLvjsP5tsQyv
kX5PNt5UKYN3gcONkCP6SuU5v7mJJEsO+zkmOdUX7e8QaHkfEMwXEsEEP8bc
4/KTpZjz5CQA+XET+trX3AcYNto7HElJj63i4Snht5GKrQtEW+7oMGT9kWyp
vZjeGyK5gRIyf1loPJYhwWREhbo+USaX5F2parxapLt/dmnvPlXUzfLEox2S
CSM3ac3UttTx0ooq5CJXILlMzqhzVWds/pc/ix41uAzXyAKQdTzL1WS34ToH
DOx8YpHD9tg1gxXtrhEz/+WvopODkELSwZ/mSGxAJ5Eq7VolG+GNtQPY3gxw
NOIlvBtssY+Qd0Z1Iyf2VNZKOX8EFOr2hIJniSb0l5aKw2xv/AkNLyDRqoXu
eMvJt3r97SmpYuKp2UhpYiNMT538sZ0ltaz2DE3w4UM4z/aEFiU4X6qKZN8X
b77L/puuj0il9OfYYhqbAL7Wd399G69m7Xa7BWJc8fLme+VoLlHx+7JxhOo5
vp2Hr94lUx6r9LfNyAmRwoqz+fRlOisqic+f+31LYrLhlYEpb/+WBdy86+b8
HJMKpe0Gtvti8LzSxqjJHS3LUxgT7w+Eq1VS23teXo4cjfdCxyM93gE9uBHG
65ThRO/vXReETPEMp9m/sin+Gl75bgxcZLy5fOwmd9ONx7E3WxyM8UXj8c3I
Y2RNpM2YI+BzWrqGvGhHsiGlRMGWD1irD0s3thp4m4yNi51AoVxJ5mobitAP
5djd9iw1tNclckifJBXidZY2VoO9jo7pwwioUq5FhEHpqXza/Z6FBE0Yljak
tigNPKNNT39HIWJJooVIxXPITBSXaOg2/wno91hsdwDxX3zLdFBAuT9peHkF
Kf4X8vdQPHkuAAA=
</rfc> </rfc>
 End of changes. 44 change blocks. 
1124 lines changed or deleted 345 lines changed or added

This html diff was produced by rfcdiff 1.48.