wdiff rfc8749xml2.original.xml rfc8749.xml

<?xml version="1.0" encoding="utf-8"?>
<!-- name="GENERATOR" content="github.com/mmarkdown/mmark Mmark Markdown Processor - mmark.nl" --> version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM 'rfc2629.dtd' []> "rfc2629-xhtml.ent">

<rfc number="8749" xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902"
     category="std" xml:lang="en" consensus="yes" updates="6698, 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"?>
     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 abbrev="Obsolete DLV">Moving DNSSEC Lookaside Validation (DLV) to Historic Status</title><author initials="W.M." Status</title>
    <seriesInfo name="RFC" value="8749"/>
    <author initials="W." surname="Mekking" fullname="Matthijs Mekking"><organization>ISC</organization><address><postal><street></street> fullname="W. (Matthijs) Mekking">
      <organization>ISC</organization>
      <address>
        <postal>
          <street/>
          <country>Netherlands</country>
</postal><email>matthijs@isc.org</email>
</address></author>
        </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> Mahoney">
      <organization>ISC</organization>
      <address>
        <postal>
          <street/>
          <country>US</country>
        </postal>
        <email>dmahoney@isc.org</email>
      </address>
    </author>
    <date year="2019" month="October" day="31"></date> month="March" year="2020"/>
    <area>Operations and Management</area><workgroup>DNS Operations</workgroup><keyword>DNS</keyword> Management</area>
    <workgroup>DNS Operations</workgroup>
    <keyword>DNS</keyword>
    <keyword>DNSSEC</keyword>
    <keyword>DLV</keyword>

<abstract><t>This
    <abstract>

      <t>This document obsoletes retires DNSSEC lookaside validation Lookaside Validation (DLV) and reclassifies
RFCs 4431 and 5074 as Historic. Furthermore, this document updates RFC 6698 by
excluding the DLV resource record from certificates, certificates and updates RFC 6840 by
excluding the DLV registries from the trust anchor selection.</t>
    </abstract>
  </front>
  <middle>
    <section anchor="introduction" title="Introduction"> numbered="true" toc="default">
      <name>Introduction</name>
      <t>DNSSEC Lookaside Validation (DLV) was introduced to assist with the
      adoption of DNSSEC <xref target="RFC4033"></xref> target="RFC4033" format="default"/> <xref target="RFC4034"></xref>
      target="RFC4034" format="default"/> <xref target="RFC4035"></xref> target="RFC4035"
      format="default"/> in a time where when the root zone and many top level top-level
      domains (TLDs) were unsigned, to help unsigned.
   DLV allowed entities with signed zones under an unsigned parent zone, zone
   or that have entities with registrars that don't did not accept DS records. records to
   publish trust anchors outside of the normal DNS delegation chain.
The root zone is was signed since in July 2010 2010, and as of May 2019,
      1389 out of 1531 TLDs have a secure delegation from the root; thus thus, DLV
      has served its purpose and can now retire.</t>
    </section>
    <section anchor="terminology" title="Terminology">
<t>The numbered="true" toc="default">
      <name>Requirements Language</name>
        <t>
    The key words &quot;MUST&quot;, &quot;MUST NOT&quot;, &quot;REQUIRED&quot;, &quot;SHALL&quot;, &quot;SHALL NOT&quot;,
&quot;SHOULD&quot;, &quot;SHOULD NOT&quot;, &quot;RECOMMENDED&quot;, &quot;NOT RECOMMENDED&quot;, &quot;MAY&quot;, "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
    "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
    NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
    "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and
&quot;OPTIONAL&quot; "<bcp14>OPTIONAL</bcp14>" in this document are
    to be interpreted as
    described in BCP&nbsp;14 <xref target="RFC2119"></xref> and target="RFC2119"/> <xref target="RFC8174"></xref>.</t> target="RFC8174"/>
    when, and only when, they appear in all capitals, as shown here.
        </t>
    </section>
    <section anchor="discussion" title="Discussion"> numbered="true" toc="default">
      <name>Discussion</name>
      <t>One could argue that DLV is still useful because there are still some unsigned
TLDs and entities under those zones that will not benefit from signing their zone.
However, keeping the DLV mechanism also has disadvantages:</t>
<t>
<list style="symbols">
<t>It
      <ul spacing="normal">
        <li>It reduces the pressure to get the parent zone signed.</t>
<t>It signed.</li>
        <li>It reduces the pressure on registrars to accept DS records.</t>
<t>It records.</li>
        <li>It complicates validation code.</t>
</list>
</t> code.</li>
      </ul>
      <t>In addition, not every validator actually implemented DLV (only BIND 9 and
Unbound)
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
registry (dlv.isc.org) and that has been (dlv.isc.org), which was deprecated (replaced with a signed
empty zone) on September 30, 2017. With the absence of a well-known DLV
registry service service, it is unlikely that there is a real benefit for the protocol
on the Internet nowadays.</t>
      <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>
      <t>All things considered considered, it is probably not worth the effort of maintaining
the DLV mechanism.</t>
    </section>
    <section anchor="moving-dlv-to-historic-status" title="Moving numbered="true" toc="default">
      <name>Moving DLV to Historic Status"> Status</name>
      <t>There are two RFCs that specify DLV:</t>
<t>
<list style="numbers">
<t>RFC
      <ol spacing="normal" type="1">
        <li>RFC 4431 <xref target="RFC4431"></xref> target="RFC4431" format="default"/> specifies the
	DLV resource record.</t>
<t>RFC record.</li>
        <li>RFC 5074 <xref target="RFC5074"></xref> target="RFC5074" format="default"/> specifies the
	DLV mechanism for publishing trust
anchors outside the DNS delegation chain and how validators can use them
to validate DNSSEC-signed data.</t>
</list>
</t> data.</li>
      </ol>
      <t>This document moves both RFC 4431 <xref target="RFC4431"></xref> target="RFC4431"
      format="default"/> and RFC 5074 <xref target="RFC5074"></xref> target="RFC5074"
      format="default"/> to
Historic status. This is a clear signal to implementers that the DLV
resource record and the DLV mechanism SHOULD NOT <bcp14>SHOULD NOT</bcp14> be implemented or deployed.</t>
      <section anchor="documents-that-reference-the-dlv-rfcs" title="Documents that reference numbered="true" toc="default">
        <name>Documents That Reference the DLV RFCs"> RFCs</name>

        <t>The RFCs that are being moved to Historic status are referenced by a couple
of other documents. RFCs.
   The sections below describe what the changes when to those documents
   due to the DLV RFCs have been being reclassified as Historic.</t> Historic.
</t>
        <section anchor="documents-that-reference-rfc-4431" title="Documents that reference numbered="true" toc="default">
          <name>Documents That Reference RFC 4431"> 4431</name>
          <t>One RFC makes reference to RFC 4431 <xref target="RFC4431"></xref>.</t> target="RFC4431" format="default"/>.</t>
          <section anchor="rfc-5074" title="RFC 5074"> numbered="true" toc="default">
            <name>RFC 5074</name>

            <t>RFC 5074 <xref target="RFC5074"></xref>, &quot;DNSSEC ("DNSSEC Lookaside Validation (DLV)&quot; (DLV)") <xref target="RFC5074"
            format="default"></xref> describes the DLV mechanism itself, and is being moved itself. This
            document moves RFC 5074 <xref target="RFC5074" format="default"/>
            to Historic status too.</t> as well.</t>
          </section>
        </section>
        <section anchor="documents-that-reference-rfc-5074" title="Documents that reference numbered="true" toc="default">
          <name>Documents That Reference RFC 5074"> 5074</name>
          <t>Three RFCs make reference to RFC 5074 <xref target="RFC5074"></xref>.</t> target="RFC5074" format="default"/>.</t>
          <section anchor="rfc-6698" title="RFC 6698"> numbered="true" toc="default">
            <name>RFC 6698</name>
            <t>RFC 6698, &quot;The 6698 ("The DNS-Based Authentication of Named Entities (DANE)
            Transport Layer Security (TLS) Protocol: TLSA&quot; TLSA") <xref target="RFC6698"></xref>
            target="RFC6698" format="default"></xref> specifies:</t>
<t>DNSSEC
            <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.</t> interest.</blockquote>
            <t>This document updates RFC 6698 <xref
            target="RFC6698" format="default"></xref> to exclude the DLV resource record from
certificates.</t>
          </section>
          <section anchor="rfc-6840" title="RFC 6840"> numbered="true" toc="default">
            <name>RFC 6840</name>
            <t>RFC 6840, &quot;Clarifications 6840 ("Clarifications and Implementation Notes for DNS Security
(DNSSEC)&quot;
            (DNSSEC)") <xref target="RFC6840"></xref> says target="RFC6840" format="default"></xref> states
            that when trust anchors come from different sources, a validator
            may choose between them based on the perceived reliability of
            those sources. But in reality reality, this does not happen in validators
            (both BIND 9 and Unbound have a an option for a DLV trust anchor
            that can be used solely as a fallback).</t>
            <t>This document updates RFC 6840 <xref target="RFC6840"
	    format="default"></xref> to exclude the DLV registries
            from the trust anchor selection.</t>
          </section>
          <section anchor="rfc-8198" title="RFC 8198"> numbered="true" toc="default">
            <name>RFC 8198</name>
            <t>RFC 8198, &quot;Aggressive 8198 ("Aggressive Use of
	    DNSSEC-Validated Cache&quot; Cache") <xref target="RFC8198"></xref> target="RFC8198" format="default"></xref> only
references RFC 5074 <xref target="RFC5074" format="default"/> because
aggressive negative caching was first proposed
there.</t>
          </section>
        </section>
      </section>
    </section>
    <section anchor="iana-considerations" title="IANA Considerations"> numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>IANA should update has updated the annotation of the DLV RR type (code 32769) to
&quot;Obsolete&quot;
"Obsolete" in the DNS Parameters "Domain Name System (DNS) Parameters" registry.</t>
    </section>
    <section anchor="security-considerations" title="Security considerations">
<t>When numbered="true" toc="default">
      <name>Security Considerations</name>

      <t> Once the DLV mechanism goes away, 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" title="Acknowledgements">
<t>Ondrej Sury numbered="false" toc="default">
      <name>Acknowledgements</name>
      <t>The authors thank <contact fullname="Ondřej Surý"/> for the 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>
</rfc>