idnits 2.17.1 draft-sury-deprecate-obsolete-resource-records-01.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: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC1035], [RFC4034]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** 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 115: '...tive DNS Servers SHOULD issue a warnin...' RFC 2119 keyword, line 118: '... 2. DNS Servers MUST NOT compress RDA...' RFC 2119 keyword, line 121: '...sive DNS Servers MAY support legacy co...' RFC 2119 keyword, line 123: '... if desired, but SHOULD warn if such i...' RFC 2119 keyword, line 124: '...PRECATED RR Types MUST be uncompressed...' (5 more instances...) -- The draft header indicates that this document updates RFC4035, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC3597, but the abstract doesn't seem to mention this, which it should. -- The abstract seems to indicate that this document updates RFC4034, but the header doesn't have an 'Updates:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC1035, updated by this document, for RFC5378 checks: 1987-11-01) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 13, 2019) is 1803 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 dnsop O. Sury 3 Internet-Draft E. Hunt 4 Updates: 1035,3597,4035 (if approved) Internet Systems Consortium 5 Intended status: Standards Track May 13, 2019 6 Expires: November 14, 2019 8 Deprecating obsolete DNS Resource Records Types 9 draft-sury-deprecate-obsolete-resource-records-01 11 Abstract 13 This document deprecates Resource Records (RR) Types that are either 14 not being used for anything meaningful or were been already made 15 obsolete by other RFCs. This document updates [RFC1035], [RFC1035], 16 [RFC4034]. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on November 14, 2019. 35 Copyright Notice 37 Copyright (c) 2019 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (https://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Deprecating MD, MF, MB, MG, MR, MINFO, MAILA, and MAILBRR 54 Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 55 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 2 56 4. Implementation Considerations . . . . . . . . . . . . . . . . 3 57 5. Security Considerations . . . . . . . . . . . . . . . . . . . 3 58 6. Operational Considerations . . . . . . . . . . . . . . . . . 4 59 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 60 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 8.1. Normative References . . . . . . . . . . . . . . . . . . 4 62 8.2. Informative References . . . . . . . . . . . . . . . . . 4 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 4 65 1. Introduction 67 [RFC1035] and other documents have defined some Resource Record (RR) 68 Types that are no longer in common use, some of which have been 69 rendered obsolete by subsequent standards, but have never been 70 clearly deprecated in the context of the DNS. In some cases there 71 have been interoperability problems between DNS implementations that 72 support these types and those that do not - for example, because of 73 DNS name compression in the wire format. Continued support for these 74 RR Types imposes a complexity cost on new implementations for little 75 benefit. 77 This document formally deprecates such RR Types, allowing 78 implementations to drop specific support for them. 80 2. Deprecating MD, MF, MB, MG, MR, MINFO, MAILA, and MAILBRR Types 82 The MD, MF, MB, MG, MR, MINFO, MAILA, and MAILB RR Types aren't used 83 in any existing standards, and this documents deprecates their usage. 84 The MD, MF, MB, MG, MR, and MINFO RR Types RDATA contain a domain 85 name that could be compressed in the RDATA section. 87 As an update to [RFC3597] and [RFC4034] this document specifies that 88 for MD, MF, MB, MG, MR, and MINFO RR types, the canonical form is 89 such that no downcasing of embedded domain names takes place, and is 90 otherwise identical to the canonical form specified in [RFC4034] 91 section 6.2. 93 3. IANA Considerations 95 This documents updates the IANA registry "Domain Name System (DNS) 96 Parameters" ([DNS-IANA]). 98 +-------+-------+------------+---------------+ 99 | TYPE | Value | Meaning | Reference | 100 +-------+-------+------------+---------------+ 101 | MD | 3 | DEPRECATED | This document | 102 | MF | 4 | DEPRECATED | This document | 103 | MB | 7 | DEPRECATED | This document | 104 | MG | 8 | DEPRECATED | This document | 105 | MR | 9 | DEPRECATED | This document | 106 | MINFO | 14 | DEPRECATED | This document | 107 +-------+-------+------------+---------------+ 109 4. Implementation Considerations 111 Types will be flagged as obsolete/deprecated in the IANA registry, 112 and the following guidance is given to DNS implementors in the 113 handling of obsolete/deprecated RR types: 115 1. Authoritative DNS Servers SHOULD issue a warning when loading 116 zones that contain DEPRECATED RR Types; 118 2. DNS Servers MUST NOT compress RDATA when rendering DEPRECATED RR 119 Types to wire format; 121 3. Recursive DNS Servers MAY support legacy compression in 122 DEPRECATED RR Types for received data for backward compatibility 123 if desired, but SHOULD warn if such information is received. 124 Compressed RDATA in DEPRECATED RR Types MUST be uncompressed 125 before sending and they MUST NOT be re-transmitted; 127 4. DNS Clients which receive DEPRECATED RR Types MAY interpret them 128 as unknown RR types ([RFC3597]), and MUST NOT interfere with 129 their transmission; 131 5. DNSSEC Validators and Signers SHOULD treat RDATA for DEPRECATED 132 RR Types as opaque with respect to canonical RR ordering and 133 deduplication; 135 6. DEPRECATED RR Types MUST never be treated as a known-type with 136 respect to the wire protocol. 138 5. Security Considerations 140 This document has no security considerations. 142 6. Operational Considerations 144 The varying states of implementation of MD, MF, MB, MG, MR, and MINFO 145 RR Types has already caused operational problems between DNS 146 implementations that do implement the aforementioned types and those 147 that don't because of DNS compression on the wire. This document 148 aims to rectify the situation by encouraging removal of support for 149 all these RR types in DNS implementations. This should not cause 150 signficant operational problems because these records are not in wide 151 use on the Internet. [COMMENT: Some data?] 153 7. Acknowledgements 155 Peter van Dijk for poking me to write the draft. Daniel Salzman for 156 reviewing the document. Evan Hunt and Michael Casadevall to write 157 Implementation Considerations section. 159 8. References 161 8.1. Normative References 163 [RFC1035] Mockapetris, P., "Domain names - implementation and 164 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 165 November 1987, . 167 [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record 168 (RR) Types", RFC 3597, DOI 10.17487/RFC3597, September 169 2003, . 171 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 172 Rose, "Resource Records for the DNS Security Extensions", 173 RFC 4034, DOI 10.17487/RFC4034, March 2005, 174 . 176 8.2. Informative References 178 [DNS-IANA] 179 "Domain Name System (DNS) Parameters", 180 . 183 Authors' Addresses 185 Ondrej Sury 186 Internet Systems Consortium 187 CZ 189 EMail: ondrej@isc.org 190 Evan Hunt 191 Internet Systems Consortium 192 US 194 EMail: each@isc.org