idnits 2.17.00 (12 Aug 2021) /tmp/idnits26963/draft-sury-dnsext-cname-dname-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) -- The draft header indicates that this document updates RFC1034, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 15, 2010) is 4418 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 normative reference: RFC 2672 (Obsoleted by RFC 6672) ** Downref: Normative reference to an Informational RFC: RFC 3743 Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNSext Working Group O. Sury 3 Internet-Draft CZ.NIC 4 Updates: 1034 (if approved) April 15, 2010 5 Intended status: Standards Track 6 Expires: October 17, 2010 8 CNAME+DNAME Name Redirection 9 draft-sury-dnsext-cname-dname-00 11 Abstract 13 This document proposes a modification to CNAME record to coexist with 14 DNAME record, which provides redirection for a sub-tree of the domain 15 name tree in the DNS system. By allowing this cooexistence, DNS 16 system will have a way how to create a sub-tree redirection together 17 with record owner. This would allow parent zones to create full 18 domain aliases. 20 Status of this Memo 22 This Internet-Draft is submitted to IETF in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 This Internet-Draft will expire on October 17, 2010. 43 Copyright Notice 45 Copyright (c) 2010 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 62 1.2. Requirements Language . . . . . . . . . . . . . . . . . . . 3 63 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 3. CNAME+DNAME Bundle . . . . . . . . . . . . . . . . . . . . . . 4 65 4. Query processing . . . . . . . . . . . . . . . . . . . . . . . 4 66 4.1. Processing by Authoritative Servers . . . . . . . . . . . . 4 67 4.2. Processing by Recursive Servers . . . . . . . . . . . . . . 5 68 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 69 6. Normative References . . . . . . . . . . . . . . . . . . . . . 5 70 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 5 72 1. Introduction 74 RFC 1034 [RFC1034] defines CNAME resource record for cases when there 75 are multiple names for single host. A CNAME resource record 76 identifies its owner name as an alias, and specifies the 77 corresponding canonical name in the RDATA section of the resource 78 record. If a CNAME resource record is present at a node, no other 79 data MUST be present; this ensures that the data for a canonical name 80 and its aliases cannot be different. This rule also insures that a 81 cached CNAME can be used without checking with an authoritative 82 server for other resource record types. 84 However there is already existing exceptions to this rule. RFC 4034 85 [RFC4034] defines exception to RRSIG and NSEC records, which MUST 86 exist for the same name as a CNAME resource record in a signed zone. 88 RFC 2672 [RFC2672] defines DNAME resource record, which provides 89 redirection for a sub-tree of the domain name tree in the DNS system. 90 That is, all names that end with a particular suffix are redirected 91 to another part of the DNS. 93 The DNAME RR and the CNAME RR RFC 1034 [RFC1034] cause a lookup to 94 (potentially) return data corresponding to a domain name different 95 from the queried domain name. The difference between the two 96 resource records is that the CNAME RR directs the lookup of data at 97 its owner to another single name, a DNAME RR directs lookups for data 98 at descendents of its owner's name to corresponding names under a 99 different (single) node of the tree. 101 1.1. Terminology 103 All the basic terms used in this specification are defined in the 104 documents RFC 1034 [RFC1034], RFC 1034 [RFC1034], RFC 2672 [RFC1034] 105 and RFC 2672bis. 107 1.2. Requirements Language 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 111 document are to be interpreted as described in RFC 2119 [RFC2119]. 113 2. Motivation 115 In some languages, some characters has the variants, which look 116 differently or very similar but are identical in the meaning. For 117 example, Chinese character U+56FD and its variant U+570B look 118 differently, but are identical in the meaning. If Internationalized 119 Domain Label" or "IDL" RFC 3743 [RFC3743] are composed of variant 120 characters, we regard this kind of IDL as the IDL variant. If these 121 IDL variants are put into the DNS for resolution, they are expected 122 to be identical in the DNS resolution. More comprehensible example 123 is that we expect color.example.com to be equivalent with the 124 colour.example.com in the DNS resolution. Currently this is 125 something we are unable to achieve without copying the data for the 126 owner of the domain record (ie. for the color.example.com) and 127 keeping it in sync by some external mechanism. The CNAME+DNAME 128 record placed in the parent zone will remove this need for 129 synchronization. Without this bundling mechanism, current mechanisms 130 such as DNAME or CNAME are not enough capable to solve all the 131 problems with the emergence of internationalized domain names. The 132 internationalized domain names may have alias or equivalence of the 133 original one. 135 The CNAME+DNAME is not limited to internationalized domain names. 136 This bundling could be used by TLD registries to offer additional 137 service for it's registrants. F.e. a hosting company could create 138 generic record for it's service and with simple CNAME+DNAME bundle it 139 can create all needed DNS resource records for providing this 140 service. 142 There are already such uses of CNAME which violates existing DNS 143 standards by replying with CNAME records in the apex of the zone. 144 This proposal would allow these perpetrators to comply with the DNS 145 standard again. 147 3. CNAME+DNAME Bundle 149 This proposal doesn't change wire formats of the existing CNAME and 150 DNAME records. It also doesn't change handling of the CNAME and 151 DNAME on the resolver side. 153 4. Query processing 155 Existing rules for a DNAME RR and a CNAME RR are still valid with one 156 exception: The DNAME resource record is allowed when there is a CNAME 157 resource record for the same name. 159 4.1. Processing by Authoritative Servers 161 The authoritative server implementations MUST allow CNAME record when 162 there is a DNAME record for the same name and vice versa. 164 4.2. Processing by Recursive Servers 166 The recursive server implementations MUST NOT deny CNAME record when 167 there is a DNAME record already present in the cache for the same 168 name and vice versa. Existing implementations are already able to 169 cope with CNAME usage violations, so there shouldn't be a problem. 171 5. Security Considerations 173 The security is the same as security of the individual CNAME and 174 DNAME records. 176 6. Normative References 178 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 179 STD 13, RFC 1034, November 1987. 181 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 182 Requirement Levels", BCP 14, RFC 2119, March 1997. 184 [RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection", 185 RFC 2672, August 1999. 187 [RFC3743] Konishi, K., Huang, K., Qian, H., and Y. Ko, "Joint 188 Engineering Team (JET) Guidelines for Internationalized 189 Domain Names (IDN) Registration and Administration for 190 Chinese, Japanese, and Korean", RFC 3743, April 2004. 192 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 193 Rose, "Resource Records for the DNS Security Extensions", 194 RFC 4034, March 2005. 196 Author's Address 198 Ondrej Sury 199 CZ.NIC 200 Americka 23 201 120 00 Praha 2 202 CZ 204 Phone: +420 222 745 110 205 Email: ondrej.sury@nic.cz