rfc8749xml2.original.xml   rfc8749.xml 
<?xml version="1.0" encoding="utf-8"?> <?xml version='1.0' encoding='utf-8'?>
<!-- name="GENERATOR" content="github.com/mmarkdown/mmark Mmark Markdown Process <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
or - mmark.nl" -->
<!DOCTYPE rfc SYSTEM 'rfc2629.dtd' []>
<rfc ipr="trust200902" category="std" xml:lang="en" consensus="yes" updates="669
8, 6840" docName="draft-ietf-dnsop-obsolete-dlv-02">
<?rfc toc="yes"?><?rfc symrefs="yes"?><?rfc sortrefs="yes"?><?rfc compact="yes"?
><?rfc subcompact="no"?><?rfc comments="no"?>
<front>
<title abbrev="obsolete-dlv">Moving DNSSEC Lookaside Validation (DLV) to Histori
c Status</title><author initials="W.M." surname="Mekking" fullname="Matthijs Mek
king"><organization>ISC</organization><address><postal><street></street>
<country>Netherlands</country>
</postal><email>matthijs@isc.org</email>
</address></author>
<author initials="D." surname="Mahoney" fullname="Dan Mahoney"><organization>ISC
</organization><address><postal><street>950 Charter St</street>
<city>Redwood City</city>
<code>94063</code>
<country>USA</country>
<region>CA</region>
</postal><email>dmahoney@isc.org</email>
</address></author>
<date year="2019" month="October" day="31"></date>
<area>Operations and Management</area><workgroup>DNS Operations</workgroup><keyw
ord>DNS</keyword>
<keyword>DNSSEC</keyword>
<keyword>DLV</keyword>
<abstract><t>This document obsoletes DNSSEC lookaside validation (DLV) and recla <rfc number="8749" xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902"
ssifies category="std" xml:lang="en" consensus="yes" updates="6698, 6840"
docName="draft-ietf-dnsop-obsolete-dlv-02" obsoletes=""
submissionType="IETF" tocInclude="true" symRefs="true" sortRefs="true"
version="3">
<!-- xml2rfc v2v3 conversion 2.38.1 -->
<front>
<title abbrev="Obsolete DLV">Moving DNSSEC Lookaside Validation (DLV) to His
toric Status</title>
<seriesInfo name="RFC" value="8749"/>
<author initials="W." surname="Mekking" fullname="W. (Matthijs) Mekking">
<organization>ISC</organization>
<address>
<postal>
<street/>
<country>Netherlands</country>
</postal>
<email>matthijs@isc.org</email>
</address>
</author>
<author initials="D." surname="Mahoney" fullname="Dan Mahoney">
<organization>ISC</organization>
<address>
<postal>
<street/>
<country>US</country>
</postal>
<email>dmahoney@isc.org</email>
</address>
</author>
<date month="March" year="2020"/>
<area>Operations and Management</area>
<workgroup>DNS Operations</workgroup>
<keyword>DNS</keyword>
<keyword>DNSSEC</keyword>
<keyword>DLV</keyword>
<abstract>
<t>This document retires DNSSEC Lookaside Validation (DLV) and reclassifie
s
RFCs 4431 and 5074 as Historic. Furthermore, this document updates RFC 6698 by RFCs 4431 and 5074 as Historic. Furthermore, this document updates RFC 6698 by
excluding the DLV resource record from certificates, and updates RFC 6840 by excluding the DLV resource record from certificates and updates RFC 6840 by
excluding the DLV registries from the trust anchor selection.</t> excluding the DLV registries from the trust anchor selection.</t>
</abstract> </abstract>
</front>
</front> <middle>
<section anchor="introduction" numbered="true" toc="default">
<middle> <name>Introduction</name>
<t>DNSSEC Lookaside Validation (DLV) was introduced to assist with the
<section anchor="introduction" title="Introduction"> adoption of DNSSEC <xref target="RFC4033" format="default"/> <xref
<t>DNSSEC Lookaside Validation (DLV) was introduced to assist with the adoption target="RFC4034" format="default"/> <xref target="RFC4035"
of format="default"/> in a time when the root zone and many top-level
DNSSEC <xref target="RFC4033"></xref> <xref target="RFC4034"></xref> <xref targe domains (TLDs) were unsigned.
t="RFC4035"></xref> in a time where the root zone DLV allowed entities with signed zones under an unsigned parent zone
and many top level domains (TLDs) were unsigned, to help entities with signed or entities with registrars that did not accept DS records to
zones under an unsigned parent zone, or that have registrars that don't accept publish trust anchors outside of the normal DNS delegation chain.
DS records. The root zone is signed since July 2010 and as of May 2019, The root zone was signed in July 2010, and as of May 2019,
1389 out of 1531 TLDs have a secure delegation from the root; thus DLV has 1389 out of 1531 TLDs have a secure delegation from the root; thus, DLV
served its purpose and can now retire.</t> has served its purpose and can now retire.</t>
</section> </section>
<section anchor="terminology" numbered="true" toc="default">
<section anchor="terminology" title="Terminology"> <name>Requirements Language</name>
<t>The key words &quot;MUST&quot;, &quot;MUST NOT&quot;, &quot;REQUIRED&quot;, & <t>
quot;SHALL&quot;, &quot;SHALL NOT&quot;, The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
&quot;SHOULD&quot;, &quot;SHOULD NOT&quot;, &quot;RECOMMENDED&quot;, &quot;NOT R "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
ECOMMENDED&quot;, &quot;MAY&quot;, and NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
&quot;OPTIONAL&quot; in this document are to be interpreted as described in "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
<xref target="RFC2119"></xref> and <xref target="RFC8174"></xref>.</t> "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are
</section> to be interpreted as
described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
<section anchor="discussion" title="Discussion"> when, and only when, they appear in all capitals, as shown here.
<t>One could argue that DLV is still useful because there are still some unsigne </t>
d </section>
TLDs and entities under those zones will not benefit from signing their zone. <section anchor="discussion" numbered="true" toc="default">
<name>Discussion</name>
<t>One could argue that DLV is still useful because there are still some u
nsigned
TLDs and entities under those zones that will not benefit from signing their zon
e.
However, keeping the DLV mechanism also has disadvantages:</t> However, keeping the DLV mechanism also has disadvantages:</t>
<t> <ul spacing="normal">
<list style="symbols"> <li>It reduces the pressure to get the parent zone signed.</li>
<t>It reduces the pressure to get the parent zone signed.</t> <li>It reduces the pressure on registrars to accept DS records.</li>
<t>It reduces the pressure on registrars to accept DS records.</t> <li>It complicates validation code.</li>
<t>It complicates validation code.</t> </ul>
</list> <t>In addition, not every validator actually implemented DLV (only BIND 9
</t> and
<t>In addition, not every validator actually implemented DLV (only BIND 9 and Unbound), so even if an entity can use DLV to set up an alternate path to its
Unbound) so even if an entity can use DLV to set up an alternate path to its trust anchor, its effect is limited. Furthermore, there was one well-known DLV
trust anchor, its effect is limited. Furthermore, there was one well-known DLV registry (dlv.isc.org), which was deprecated (replaced with a signed
registry (dlv.isc.org) and that has been deprecated (replaced with a signed
empty zone) on September 30, 2017. With the absence of a well-known DLV empty zone) on September 30, 2017. With the absence of a well-known DLV
registry service it is unlikely that there is a real benefit for the protocol registry service, it is unlikely that there is a real benefit for the protocol
on the Internet nowadays.</t> on the Internet nowadays.</t>
<t>One other possible reason to keep DLV is to distribute trust anchors <t>One other possible reason to keep DLV is to distribute trust anchors
for private enterprises. There are no known uses of DLV for this.</t> for private enterprises. There are no known uses of DLV for this.</t>
<t>All things considered it is probably not worth the effort of maintaining <t>All things considered, it is probably not worth the effort of maintaini
ng
the DLV mechanism.</t> the DLV mechanism.</t>
</section> </section>
<section anchor="moving-dlv-to-historic-status" numbered="true" toc="default
<section anchor="moving-dlv-to-historic-status" title="Moving DLV to Historic St ">
atus"> <name>Moving DLV to Historic Status</name>
<t>There are two RFCs that specify DLV:</t> <t>There are two RFCs that specify DLV:</t>
<t> <ol spacing="normal" type="1">
<list style="numbers"> <li>RFC 4431 <xref target="RFC4431" format="default"/> specifies the
<t>RFC 4431 <xref target="RFC4431"></xref> specifies the DLV resource record.</t DLV resource record.</li>
> <li>RFC 5074 <xref target="RFC5074" format="default"/> specifies the
<t>RFC 5074 <xref target="RFC5074"></xref> specifies the DLV mechanism for publi DLV mechanism for publishing trust
shing trust
anchors outside the DNS delegation chain and how validators can use them anchors outside the DNS delegation chain and how validators can use them
to validate DNSSEC-signed data.</t> to validate DNSSEC-signed data.</li>
</list> </ol>
</t> <t>This document moves both RFC 4431 <xref target="RFC4431"
<t>This document moves both RFC 4431 <xref target="RFC4431"></xref> and RFC 5074 format="default"/> and RFC 5074 <xref target="RFC5074"
<xref target="RFC5074"></xref> to format="default"/> to
Historic status. This is a clear signal to implementers that the DLV Historic status. This is a clear signal to implementers that the DLV
resource record and the DLV mechanism SHOULD NOT be implemented or deployed.</t> resource record and the DLV mechanism <bcp14>SHOULD NOT</bcp14> be implemented o
r deployed.</t>
<section anchor="documents-that-reference-the-dlv-rfcs" title="Documents that re <section anchor="documents-that-reference-the-dlv-rfcs" numbered="true" to
ference the DLV RFCs"> c="default">
<t>The RFCs that are being moved to Historic status are referenced by a couple <name>Documents That Reference the DLV RFCs</name>
of other documents. The sections below describe what changes when the DLV
RFCs have been reclassified as Historic.</t>
<section anchor="documents-that-reference-rfc-4431" title="Documents that refere
nce RFC 4431">
<t>One RFC makes reference to RFC 4431 <xref target="RFC4431"></xref>.</t>
<section anchor="rfc-5074" title="RFC 5074">
<t>RFC 5074 <xref target="RFC5074"></xref>, &quot;DNSSEC Lookaside Validation (D
LV)&quot; describes the DLV
mechanism itself, and is being moved to Historic status too.</t>
</section>
</section>
<section anchor="documents-that-reference-rfc-5074" title="Documents that refere <t>The RFCs being moved to Historic status are referenced by a couple
nce RFC 5074"> of other RFCs.
<t>Three RFCs make reference to RFC 5074 <xref target="RFC5074"></xref>.</t> The sections below describe the changes to those documents
due to the DLV RFCs being reclassified as Historic.
</t>
<section anchor="documents-that-reference-rfc-4431" numbered="true" toc=
"default">
<name>Documents That Reference RFC 4431</name>
<t>One RFC makes reference to RFC 4431 <xref target="RFC4431" format="
default"/>.</t>
<section anchor="rfc-5074" numbered="true" toc="default">
<name>RFC 5074</name>
<section anchor="rfc-6698" title="RFC 6698"> <t>RFC 5074 ("DNSSEC Lookaside Validation (DLV)") <xref target="RFC5
<t>RFC 6698, &quot;The DNS-Based Authentication of Named Entities (DANE) Transpo 074"
rt format="default"></xref> describes the DLV mechanism itself. This
Layer Security (TLS) Protocol: TLSA&quot; <xref target="RFC6698"></xref> specifi document moves RFC 5074 <xref target="RFC5074" format="default"/>
es:</t> to Historic status as well.</t>
<t>DNSSEC forms certificates (the binding of an identity to a key) by </section>
combining a DNSKEY, DS, or DLV resource record with an associated RRSIG </section>
record. These records then form a signing chain extending from the <section anchor="documents-that-reference-rfc-5074" numbered="true" toc=
client's trust anchors to the RR of interest.</t> "default">
<t>This document updates RFC 6698 to exclude the DLV resource record from <name>Documents That Reference RFC 5074</name>
<t>Three RFCs make reference to RFC 5074 <xref target="RFC5074" format
="default"/>.</t>
<section anchor="rfc-6698" numbered="true" toc="default">
<name>RFC 6698</name>
<t>RFC 6698 ("The DNS-Based Authentication of Named Entities (DANE)
Transport Layer Security (TLS) Protocol: TLSA") <xref
target="RFC6698" format="default"></xref> specifies:</t>
<blockquote>DNSSEC forms certificates (the binding of an identity to
a key) by
combining a DNSKEY, DS, or DLV resource record with an
associated RRSIG
record. These records then form a signing chain extending from the
client's trust anchors to the RR of interest.</blockquote>
<t>This document updates RFC 6698 <xref
target="RFC6698" format="default"></xref> to exclude the DLV resourc
e record from
certificates.</t> certificates.</t>
</section> </section>
<section anchor="rfc-6840" numbered="true" toc="default">
<section anchor="rfc-6840" title="RFC 6840"> <name>RFC 6840</name>
<t>RFC 6840, &quot;Clarifications and Implementation Notes for DNS Security <t>RFC 6840 ("Clarifications and Implementation Notes for DNS Securi
(DNSSEC)&quot; <xref target="RFC6840"></xref> says that when trust anchors come ty
from different (DNSSEC)") <xref target="RFC6840" format="default"></xref> states
sources, a validator may choose between them based on the perceived that when trust anchors come from different sources, a validator
reliability of those sources. But in reality this does not happen in may choose between them based on the perceived reliability of
validators (both BIND 9 and Unbound have a option for a DLV trust anchor those sources. But in reality, this does not happen in validators
that can be used solely as a fallback).</t> (both BIND 9 and Unbound have an option for a DLV trust anchor
<t>This document updates RFC 6840 to exclude the DLV registries from the trust that can be used solely as a fallback).</t>
anchor selection.</t> <t>This document updates RFC 6840 <xref target="RFC6840"
</section> format="default"></xref> to exclude the DLV registries
from the trust anchor selection.</t>
<section anchor="rfc-8198" title="RFC 8198"> </section>
<t>RFC 8198, &quot;Aggressive Use of DNSSEC-Validated Cache&quot; <xref target=" <section anchor="rfc-8198" numbered="true" toc="default">
RFC8198"></xref> only <name>RFC 8198</name>
references RFC 5074 because aggressive negative caching was first proposed <t>RFC 8198 ("Aggressive Use of
DNSSEC-Validated Cache") <xref target="RFC8198" format="default"></xr
ef> only
references RFC 5074 <xref target="RFC5074" format="default"/> because
aggressive negative caching was first proposed
there.</t> there.</t>
</section> </section>
</section> </section>
</section> </section>
</section> </section>
<section anchor="iana-considerations" numbered="true" toc="default">
<section anchor="iana-considerations" title="IANA Considerations"> <name>IANA Considerations</name>
<t>IANA should update the annotation of the DLV RR type (code 32769) to <t>IANA has updated the annotation of the DLV RR type (code 32769) to
&quot;Obsolete&quot; in the DNS Parameters registry.</t> "Obsolete" in the "Domain Name System (DNS) Parameters" registry.</t>
</section> </section>
<section anchor="security-considerations" numbered="true" toc="default">
<section anchor="security-considerations" title="Security considerations"> <name>Security Considerations</name>
<t>When the DLV mechanism goes away, zones that rely on DLV for their
validation will be treated as insecure. The chance that this scenario actually
occurs is very low, since no well-known DLV registry exists.</t>
</section>
<section anchor="acknowledgements" title="Acknowledgements">
<t>Ondrej Sury for initial review.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5074.xml
"?>
<?rfc include="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6698.xml
"?>
<?rfc include="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6840.xml
"?>
<?rfc include="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4034.xml
"?>
<?rfc include="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml
"?>
<?rfc include="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml
"?>
<?rfc include="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8198.xml
"?>
<?rfc include="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4033.xml
"?>
<?rfc include="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4035.xml
"?>
<?rfc include="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4431.xml
"?>
</references>
</back>
<t> Once the DLV mechanism is retired, zones that rely on DLV for their
validation will be treated as insecure. The chance that this scenario
actually occurs is very low, since no well-known DLV registry
exists.</t>
</section>
</middle>
<back>
<references>
<name>Normative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.5074.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.6698.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.6840.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.4034.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.2119.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.8174.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.8198.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.4033.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.4035.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.4431.xml"/>
</references>
<section anchor="acknowledgements" numbered="false" toc="default">
<name>Acknowledgements</name>
<t>The authors thank <contact fullname="Ondřej Surý"/> for the initial rev
iew.</t>
</section>
</back>
</rfc> </rfc>
 End of changes. 14 change blocks. 
190 lines changed or deleted 222 lines changed or added

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