idnits 2.17.1 draft-mekking-dnsop-obsolete-dlv-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 266 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 123: '...he DLV mechanism SHOULD NOT be impleme...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 2, 2019) is 1759 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-02) exists of draft-lhotka-dnsop-iana-class-type-yang-01 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNS Operations W. Mekking 3 Internet-Draft D. Mahoney 4 Intended status: Informational ISC 5 Expires: January 3, 2020 July 2, 2019 7 Moving DNSSEC Lookaside Validation (DLV) to Historic Status 8 draft-mekking-dnsop-obsolete-dlv-00 10 Abstract 12 This document obsoletes DNSSEC lookaside validation (DLV) and 13 reclassifies RFCs 4431 and 5074 as Historic. 15 Status of This Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at https://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 This Internet-Draft will expire on January 3, 2020. 32 Copyright Notice 34 Copyright (c) 2019 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (https://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. Code Components extracted from this document must 43 include Simplified BSD License text as described in Section 4.e of 44 the Trust Legal Provisions and are provided without warranty as 45 described in the Simplified BSD License. 47 Table of Contents 49 1. Introduction 50 2. Discussion 51 3. Moving DLV to Historic Status 52 3.1. Documents that reference the DLV RFCs 53 3.1.1. Documents that reference RFC 4431 54 3.1.2. Documents that reference RFC 5074 55 4. IANA Considerations 56 5. Security considerations 57 6. Acknowledgements 58 7. Normative References 59 Authors' Addresses 61 1. Introduction 63 DNSSEC Lookaside Validation (DLV) was introduced to assist with the 64 adoption of DNSSEC [RFC4033] [RFC4034] [RFC4035] in a time where the 65 root zone and many top level domains (TLDs) were unsigned, to help 66 entities with signed zones under an unsigned parent zone, or that 67 have registrars that don't accept DS records. As of May 2019, the 68 root zone is signed and 1389 out of 1531 TLDs have a secure 69 delegation from the root; thus DLV has served its purpose and can now 70 retire. 72 2. Discussion 74 One could argue that DLV is still useful because there are still some 75 unsigned TLDs and entities under those zones will not benefit from 76 signing their zone. However, keeping the DLV mechanism also has 77 disadvantages: 79 o It reduces the pressure to get the parent zone signed. 81 o It reduces the pressure on registrars to accept DS records. 83 o It complicates validation code. 85 In addition, not every validator actually implements DLV (only BIND 9 86 and Unbound) so even if an entity can use DLV to set up an alternate 87 path to its trust anchor, its effect is limited. Furthermore, there 88 was one well-known DLV registry (dlv.isc.org) and that has been 89 deprecated (replaced with a signed empty zone) on September 30, 2017. 90 With the absence of a well-known DLV registry service it is unlikely 91 that there is a real benefit for the protocol on the Internet 92 nowadays. 94 One other possible reason to keep DLV is to distribute trust anchors 95 for private enterprises. However it was never the intention for DLV 96 to be used for this purpose, and DLV has some properties that do not 97 entirely fit this use case: 99 o It would be more desirable if the trust anchors for internal zones 100 have a higher priority than the public trust anchors, but DLV 101 works as a fallback. 103 o Since the zones are related to private networks, it would make 104 more sense to make the internal network more secure to avoid name 105 redirection, rather than complicate the DNS protocol. 107 Given these arguments, plus its fairly limited use case, and the 108 above disadvantages to keep DLV, it is probably not worth the effort 109 of maintaining the DLV mechanism. 111 3. Moving DLV to Historic Status 113 There are two RFCs that specify DLV: 115 1. RFC 4431 [RFC4431] specifies the DLV resource record. 117 2. RFC 5074 [RFC5074] specifies the DLV mechanism for publishing 118 trust anchors outside the DNS delegation chain and how validators 119 can use them to validate DNSSEC-signed data. 121 This document moves both RFC 4431 [RFC4431] and RFC 5074 [RFC5074] to 122 Historic status. This is a clear signal to implementers that the DLV 123 resource record and the DLV mechanism SHOULD NOT be implemented or 124 deployed. 126 3.1. Documents that reference the DLV RFCs 128 The RFCs that are being moved to Historic status are referenced by a 129 couple of other documents. The sections below describe what changes 130 when the DLV RFCs have been reclassified as Historic. 132 3.1.1. Documents that reference RFC 4431 134 One RFC and one Internet Draft make reference to RFC 4431 [RFC4431]. 136 3.1.1.1. RFC 5074 138 RFC 5074 [RFC5074], "DNSSEC Lookaside Validation (DLV)" describes the 139 DLV mechanism itself, and is being moved to Historic status too. 141 3.1.1.2. I-D.lhotka-dnsop-iana-class-type-yang 143 The draft "YANG Types for DNS Classes and Resource Record Types" 144 [I-D.lhotka-dnsop-iana-class-type-yang] refers to RFC 4431 to 145 describe the DLV entry in the YANG module iana-dns-class-rr-type. 146 This reference should be removed. 148 3.1.2. Documents that reference RFC 5074 150 Three RFCs make reference to RFC 5074 [RFC5074]. 152 3.1.2.1. RFC 6698 154 RFC 6698, "The DNS-Based Authentication of Named Entities (DANE) 155 Transport Layer Security (TLS) Protocol: TLSA" [RFC6698] specifies: 157 DNSSEC forms certificates (the binding of an identity to a key) by 158 combining a DNSKEY, DS, or DLV resource record with an associated 159 RRSIG record. These records then form a signing chain extending from 160 the client's trust anchors to the RR of interest. 162 This document updates RFC 6698 to exclude the DLV resource record 163 from certificates. 165 3.1.2.2. RFC 6840 167 RFC 6840, "Clarifications and Implementation Notes for DNS Security 168 (DNSSEC)" [RFC6840] says that when trust anchors come from different 169 sources, a validator may choose between them based on the perceived 170 reliability of those sources. But in reality this does not happen in 171 validators (both BIND 9 and Unbound have a option for a DLV trust 172 anchor that can be used solely as a fallback). 174 This document updates RFC 6840 to exclude the DLV registries from the 175 trust anchor selection. 177 3.1.2.3. RFC 8198 179 RFC 8198, "Aggressive Use of DNSSEC-Validated Cache" [RFC8198] only 180 references RFC 5074 because aggressive negative caching was first 181 proposed there. 183 4. IANA Considerations 185 IANA should update the annotation of the DLV RR type (code 32769) to 186 "Obsolete" in the DNS Parameters registry. 188 5. Security considerations 190 When the DLV mechanism goes away, zones that rely on DLV for their 191 validation will be treated as insecure. The chance that this 192 scenario actually occurs is very low, since no well-known DLV 193 registry exists. 195 6. Acknowledgements 197 Ondřej Sury for initial review. 199 7. Normative References 201 [I-D.lhotka-dnsop-iana-class-type-yang] 202 Lhotka, L. and P. Spacek, "YANG Types for DNS Classes and 203 Resource Record Types", draft-lhotka-dnsop-iana-class- 204 type-yang-01 (work in progress), February 2019. 206 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 207 Rose, "DNS Security Introduction and Requirements", 208 RFC 4033, DOI 10.17487/RFC4033, March 2005, 209 . 211 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 212 Rose, "Resource Records for the DNS Security Extensions", 213 RFC 4034, DOI 10.17487/RFC4034, March 2005, 214 . 216 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 217 Rose, "Protocol Modifications for the DNS Security 218 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, 219 . 221 [RFC4431] Andrews, M. and S. Weiler, "The DNSSEC Lookaside 222 Validation (DLV) DNS Resource Record", RFC 4431, 223 DOI 10.17487/RFC4431, February 2006, 224 . 226 [RFC5074] Weiler, S., "DNSSEC Lookaside Validation (DLV)", RFC 5074, 227 DOI 10.17487/RFC5074, November 2007, 228 . 230 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 231 of Named Entities (DANE) Transport Layer Security (TLS) 232 Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 233 2012, . 235 [RFC6840] Weiler, S., Ed. and D. Blacka, Ed., "Clarifications and 236 Implementation Notes for DNS Security (DNSSEC)", RFC 6840, 237 DOI 10.17487/RFC6840, February 2013, 238 . 240 [RFC8198] Fujiwara, K., Kato, A., and W. Kumari, "Aggressive Use of 241 DNSSEC-Validated Cache", RFC 8198, DOI 10.17487/RFC8198, 242 July 2017, . 244 Authors' Addresses 246 Matthijs Mekking 247 ISC 248 950 Charter St 249 Redwood City, CA 94063 250 Netherlands 252 Email: matthijs@isc.org 254 Dan Mahoney 255 ISC 256 950 Charter St 257 Redwood City, CA 94063 258 USA 260 Email: dmahoney@isc.org