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 "MUST", "MUST NOT", "REQUIRED", & | <t> | |||
quot;SHALL", "SHALL NOT", | The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", | |||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT R | "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL | |||
ECOMMENDED", "MAY", and | NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", | |||
"OPTIONAL" 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 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>, "DNSSEC Lookaside Validation (D | ||||
LV)" 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, "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" <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, "Clarifications and Implementation Notes for DNS Security | <t>RFC 6840 ("Clarifications and Implementation Notes for DNS Securi | |||
(DNSSEC)" <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, "Aggressive Use of DNSSEC-Validated Cache" <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 | |||
"Obsolete" 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/ |