idnits 2.17.1 draft-sury-dnsop-cname-plus-dname-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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC1034, 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 (July 15, 2018) is 2111 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) -- Obsolete informational reference (is this intentional?): RFC 7816 (Obsoleted by RFC 9156) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 dnsop O. Sury 3 Internet-Draft Internet Systems Consortium 4 Updates: 1034 (if approved) July 15, 2018 5 Intended status: Standards Track 6 Expires: January 16, 2019 8 CNAME+DNAME Name Redirection 9 draft-sury-dnsop-cname-plus-dname-01 11 Abstract 13 This document updates RFC1034 to allow coexistence of the CNAME 14 Resource Record with DNAME Resource Record at the same owner node, 15 which provides redirection for a sub-tree of the domain name tree in 16 the DNS system, in a parent zone. By allowing this cooexistence, DNS 17 system will have a way how to create a sub-tree redirection together 18 that includes the Resource Records owner name. This would allow 19 parent zones to create full domain aliases. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on January 16, 2019. 38 Copyright Notice 40 Copyright (c) 2018 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 3 58 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. CNAME+DNAME Bundle . . . . . . . . . . . . . . . . . . . . . 4 60 4. Query processing . . . . . . . . . . . . . . . . . . . . . . 4 61 4.1. Processing by Authoritative Servers . . . . . . . . . . . 4 62 4.2. Processing by Recursive Servers . . . . . . . . . . . . . 4 63 5. Implementation Report . . . . . . . . . . . . . . . . . . . . 4 64 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 65 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 66 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 8.1. Normative References . . . . . . . . . . . . . . . . . . 5 68 8.2. Informative References . . . . . . . . . . . . . . . . . 5 69 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 71 1. Introduction 73 RFC 1034 [RFC1034] defines CNAME resource record for cases when there 74 are multiple names for single host. A CNAME resource record 75 identifies its owner name as an alias, and specifies the 76 corresponding canonical name in the RDATA section of the resource 77 record. If a CNAME resource record is present at a node, no other 78 data MUST be present; this ensures that the data for a canonical name 79 and its aliases cannot be different. This rule also insures that a 80 cached CNAME can be used without checking with an authoritative 81 server for other resource record types. 83 However there is already existing exceptions to this rule. RFC 4034 84 [RFC4034] defines exception to RRSIG and NSEC records, which MUST 85 exist for the same name as a CNAME resource record in a signed zone. 87 RFC 6672 [RFC6672] defines DNAME resource record, which provides 88 redirection for a sub-tree of the domain name tree in the DNS system. 89 That is, all names that end with a particular suffix are redirected 90 to another part of the DNS. 92 The DNAME RR and the CNAME RR RFC 1034 [RFC1034] cause a lookup to 93 (potentially) return data corresponding to a domain name different 94 from the queried domain name. The difference between the two 95 resource records is that the CNAME RR directs the lookup of data at 96 its owner to another single name, a DNAME RR directs lookups for data 97 at descendents of its owner's name to corresponding names under a 98 different (single) node of the tree. 100 1.1. Terminology 102 All the basic terms used in this specification are defined in the 103 documents RFC 1034 [RFC1034], RFC 1035 [RFC1035], and RFC 6672 104 [RFC6672]. 106 1.2. Requirements Language 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 110 document are to be interpreted as described in RFC 2119 [RFC2119]. 112 2. Motivation 114 In some languages, some characters has the variants, which look 115 differently or very similar but are identical in the meaning. For 116 example, Chinese character U+56FD and its variant U+570B look 117 differently, but are identical in the meaning. If Internationalized 118 Domain Label or "IDL" RFC 3743 [RFC3743] are composed of variant 119 characters, we regard this kind of IDL as the IDL variant. If these 120 IDL variants are put into the DNS for resolution, they are expected 121 to be identical in the DNS resolution. More comprehensible example 122 is that we expect color.example.com to be equivalent with the 123 colour.example.com in the DNS resolution. Currently this is 124 something we are unable to achieve without copying the data for the 125 owner of the domain record (ie. for the color.example.com) and 126 keeping it in sync by some external mechanism. The CNAME+DNAME 127 record placed in the parent zone will remove this need for 128 synchronization. Without this bundling mechanism, current mechanisms 129 such as DNAME or CNAME are not enough capable to solve all the 130 problems with the emergence of internationalized domain names. The 131 internationalized domain names may have alias or equivalence of the 132 original one. 134 The CNAME+DNAME is not limited to internationalized domain names. 135 This bundling could be used by TLD registries to offer additional 136 service for it's registrants. F.e. a hosting company could create 137 generic record for it's service and with simple CNAME+DNAME bundle it 138 can create all needed DNS resource records for providing this 139 service. 141 There are already such uses of CNAME which violates existing DNS 142 standards by replying with CNAME records in the apex of the zone. 143 This proposal would allow these perpetrators to comply with the DNS 144 standard again. 146 3. CNAME+DNAME Bundle 148 This proposal doesn't change wire formats of the existing CNAME and 149 DNAME records. It also doesn't change handling of the CNAME and 150 DNAME on the resolver side. 152 4. Query processing 154 Existing rules for a DNAME RR and a CNAME RR are still valid with 155 following exception: The DNAME and CNAME resource records MAY co- 156 exist at the same owner name in the parent zone. 158 4.1. Processing by Authoritative Servers 160 The authoritative server implementations MUST allow CNAME record when 161 there is a DNAME record for the same name and vice versa. 163 The authoritative server implementations compliant with this 164 specification SHOULD add an associated DNAME record into an 165 ADDITIONAL (or ANSWER?) section for any non-DNAME query along with 166 the CNAME record that would be normally required. This would allow 167 recursive DNS server implementation that understand the DNAME record 168 to synthetize the answers for the subtree directly without making an 169 additional queries to the respective authoritative DNS servers. 171 4.2. Processing by Recursive Servers 173 The recursive server implementations MUST NOT deny CNAME record when 174 there is a DNAME record already present in the cache for the same 175 name and vice versa. 177 The recursive DNS server implementation SHOULD accept the extra DNAME 178 resource record that would be returned along with the CNAME record in 179 the ADDITIONAL (or ANSWER?) section. 181 5. Implementation Report 183 The author has implemented a change for BIND 9 authoritative server 184 during the IETF Hackathon in Montreal, and the domain with 185 CNAME+DNAME can be tested at www.cname-plus-dname.rocks. 187 The conducted experiment confirmed that BIND, Unbound and Google 188 Public DNS work fine, Knot Resolver has a bug that makes the DNS 189 answer contain the DNAME records, but with RCODE=SERVFAIL, and 190 PowerDNS returns RCODE=SERVFAIL for any DNAME query. The other 191 public DNS implementations follow the errors of their respective 192 deployed software. 194 6. Security Considerations 196 In case the recursive DNS server looking for records has enabled DNS 197 Query Name Minimization (RFC 7816 [RFC7816]), the CNAME+DNAME 198 specification might make the resolver send one more label than needed 199 from the original DNS Query Name to the nameservers authoritative for 200 the CNAME+DNAME records unless the authoritative DNS server 201 preemptively returns DNAME record along with the CNAME resource 202 record for the minimized query, and at the same time the recursive 203 DNS server understand the additional data in the answer and utilizes 204 it to synthetize the answer. 206 7. IANA Considerations 208 This document makes no requests of IANA. 210 8. References 212 8.1. Normative References 214 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 215 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 216 . 218 [RFC1035] Mockapetris, P., "Domain names - implementation and 219 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 220 November 1987, . 222 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 223 Requirement Levels", BCP 14, RFC 2119, 224 DOI 10.17487/RFC2119, March 1997, 225 . 227 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 228 Rose, "Resource Records for the DNS Security Extensions", 229 RFC 4034, DOI 10.17487/RFC4034, March 2005, 230 . 232 [RFC6672] Rose, S. and W. Wijngaards, "DNAME Redirection in the 233 DNS", RFC 6672, DOI 10.17487/RFC6672, June 2012, 234 . 236 8.2. Informative References 238 [RFC3743] Konishi, K., Huang, K., Qian, H., and Y. Ko, "Joint 239 Engineering Team (JET) Guidelines for Internationalized 240 Domain Names (IDN) Registration and Administration for 241 Chinese, Japanese, and Korean", RFC 3743, 242 DOI 10.17487/RFC3743, April 2004, 243 . 245 [RFC7816] Bortzmeyer, S., "DNS Query Name Minimisation to Improve 246 Privacy", RFC 7816, DOI 10.17487/RFC7816, March 2016, 247 . 249 Author's Address 251 Ondrej Sury 252 Internet Systems Consortium 253 CZ 255 Email: ondrej@isc.org