idnits 2.17.1 draft-yao-dnsop-xname-loop-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: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 256 has weird spacing: '...mapping b;...' == Line 257 has weird spacing: '...mapping c;...' == The document doesn't use any RFC 2119 keywords, yet has text resembling RFC 2119 boilerplate text. == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 14, 2011) is 4540 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2672bis' is defined on line 339, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2672 (Obsoleted by RFC 6672) == Outdated reference: A later version (-06) exists of draft-yao-dnsext-bname-05 -- Duplicate reference: RFC2672, mentioned in 'RFC2672bis', was also mentioned in 'RFC2672'. -- Obsolete informational reference (is this intentional?): RFC 2672 (Obsoleted by RFC 6672) Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Yao 3 Internet-Draft X. Lee 4 Intended status: Informational CNNIC 5 Expires: May 17, 2012 November 14, 2011 7 xNAME loop detection and its usage suggestion 8 draft-yao-dnsop-xname-loop-00.txt 10 Abstract 12 The Domain Name System (DNS) has provided some means, such as CNAME 13 or DNAME, where a query can be redirected to a different name. The 14 zone operator should be careful about this redirection, which may 15 forms a loop. The detail analysis of xNAME loop detection and its 16 impacts are not specified in the RFC 1035 and RFC 2672. This 17 document gives a detail analysis of xNAME loop and its impacts. It 18 also gives some advices for using xNAME. 20 Status of this Memo 22 This Internet-Draft is submitted 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). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 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 This Internet-Draft will expire on May 17, 2012. 37 Copyright Notice 39 Copyright (c) 2011 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 This document may contain material from IETF Documents or IETF 53 Contributions published or made publicly available before November 54 10, 2008. The person(s) controlling the copyright in some of this 55 material may not have granted the IETF Trust the right to allow 56 modifications of such material outside the IETF Standards Process. 57 Without obtaining an adequate license from the person(s) controlling 58 the copyright in such materials, this document may not be modified 59 outside the IETF Standards Process, and derivative works of it may 60 not be created outside the IETF Standards Process, except to format 61 it for publication as an RFC or to translate it into languages other 62 than English. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Single xNAME . . . . . . . . . . . . . . . . . . . . . . . . . 3 69 2.1. a CNAME b . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 2.2. a DNAME b . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 2.3. a BNAME b . . . . . . . . . . . . . . . . . . . . . . . . . 4 72 3. Single-mapping and Multi-mapping . . . . . . . . . . . . . . . 4 73 4. Combination of xNAMEs . . . . . . . . . . . . . . . . . . . . . 4 74 4.1. Combination of xNAMEs of the same type . . . . . . . . . . 4 75 4.1.1. CNAME chain . . . . . . . . . . . . . . . . . . . . . . 4 76 4.1.2. DNAME chain . . . . . . . . . . . . . . . . . . . . . . 5 77 4.1.3. BNAME chain . . . . . . . . . . . . . . . . . . . . . . 5 78 4.2. Combination of xNAMEs of the different types . . . . . . . 6 79 5. Suggestion of xNAME use . . . . . . . . . . . . . . . . . . . . 7 80 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 81 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 82 8. Change History . . . . . . . . . . . . . . . . . . . . . . . . 7 83 8.1. draft-yao-dnsop-xNAME-loop: Version 00 . . . . . . . . . . 7 84 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 85 9.1. Normative References . . . . . . . . . . . . . . . . . . . 8 86 9.2. Informative References . . . . . . . . . . . . . . . . . . 8 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 89 1. Introduction 91 RFC 1035 defines the canonical name (CNAME) RR, which directs itself 92 to other names. RFC 2672 defines the DNAME RR, which directs its 93 descedants to other names. There has been a proposal for another 94 redirection RR, "BNAME", which will direct both itself and its 95 descedants to other names. In addition, as specified in [RFC2672], 96 redirection through a DNAME also results in the synthesis of a CNAME 97 RR in the response; as described in [I-D.yao-dnsext-bname], 98 redirection through a BNAME also results in the synthesis of a CNAME 99 RR in the response In this document, we will refer to all RRs causing 100 such redirection as xNAME RRs. Naming loops can be created with 101 CNAME, DNAME or BNAME record alone, or any combinations of CNAME, 102 DNAME and BNAME records. Implementors should note, however, that 103 fairly lengthy chains of xNAME records may be valid. The zone 104 operator should be careful about this redirection, which may forms a 105 loop. However, the detail analysis of name loop detection and its 106 impacts are not specified in the RFC 1035 and RFC 2672. This 107 document gives a detail analysis of xNAME loop and its impacts. It 108 also gives some advices for using xNAME. 110 xNAME RRs can be explicitly retrieved by querying for the xNAME type. 111 When a different type is queried and an xNAME RR is encountered, the 112 xNAME RR (and possibly a synthesized CNAME) is added to the answer of 113 the response, and the query is restarted with the name to which it 114 was redirected. An xNAME may redirect a query to a name at which 115 there is another xNAME and so on. In this document, we use "xNAME 116 chain" to refer to a series of one or more xNAMEs each of which 117 refers to another xNAME except the last, which may refer to a non- 118 xNAME or results in an error. 120 1.1. Terminology 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 124 document are to be interpreted as described in [RFC2119] 126 All the basic terms used in this specification are defined in the 127 documents [RFC1034] and [RFC1035]. 129 2. Single xNAME 131 If there is only one xNAME which does not creat any chain, it will 132 not cause a xNAME loop. 134 2.1. a CNAME b 136 A single CNAME RR identifies its owner name as an alias. If a CNAME 137 b, and b refers to a non-xNAME or results in an error, it will not 138 cause the loop. 140 2.2. a DNAME b 142 A single DNAME RR directs its descedants to other names. If a DNAME 143 b, and b refers to a non-xNAMEor results in an error, it will not 144 cause the loop. 146 2.3. a BNAME b 148 A single BNAME RR directs both the owner name itself and its 149 descedants to other names. If a BNAME b, and b refers to a non-xNAME 150 or results in an error, it will not cause the loop. 152 3. Single-mapping and Multi-mapping 154 The resource record "a CNAME b" creates a one-to-one mapping, which 155 means that name a is redirected to b. We call such mapping as 156 single-mapping, and such xNAME as single-mapping xNAME. The resource 157 record "a DNAME b" or "a BNAME b" create a many-to-many mapping, 158 which means that many names under a is redirected to many names under 159 b. We call such mapping as multi-mapping, and such xNAME as multi- 160 mapping xNAME. 162 4. Combination of xNAMEs 164 4.1. Combination of xNAMEs of the same type 166 It is possible to form a xNAME loop due to the same types. 168 4.1.1. CNAME chain 170 CNAME can form a long chain. We can chain together CNAME records, 171 which may lead to create a CNAME loop. For example, 173 a CNAME b 174 b CNAME c 175 c CNAME d 177 In this case, d may point to another CNAME or a non-xNAME or results 178 in an error. CNAME is a kind of one to one mapping, which means that 179 one name points or maps to only one name. The resolver can detect 180 the loop, just following the chain. 182 4.1.2. DNAME chain 184 DNAME can form a long chain. We can chain together DNAME records, 185 which may lead to create a DNAME loop. For example, 187 a DNAME b 188 b DNAME c 189 c DNAME d 191 In this case, d may point to another DNAME or a non-xNAME or results 192 in an error. DNAME is a kind of many to many mapping, which means 193 that many names point or map to many names. The resolver can not 194 easily detect the loop. Using the example above, for any X which is 195 a valid name string, we have 197 X.a CNAME X.b 198 X.b CNAME X.c 199 X.c CNAME X.d 201 In this case, in order to detect whether it forms a loop, it must 202 check every name under "d" domain while "d" may have millions of 203 names or thousands of sub-zones. If the domain "a" and "d" are not 204 under the control of the same owner, detection of dname loop are 205 impossilbe if "a" and "d" have too many childrens. 207 4.1.3. BNAME chain 209 BNAME can form a long chain. we can chain together BNAME records, 210 which may lead to create a BNAME loop. For example, 212 a BNAME b 213 b BNAME c 214 c BNAME d 216 In this case, d may point to another BNAME or a non-xNAME or results 217 in an error. BNAME is a kind of many to many mapping, which means 218 that many names point or map to many names. The resolver can not 219 easily detect the loop. Using the example above, for any X which is 220 a valid name string, we have 222 X.a CNAME X.b 223 X.b CNAME X.c 224 X.c CNAME X.d 226 In this case, in order to detect whether it forms a loop, it must 227 check every name under "d" domain while "d" may have millions of 228 names or thousands of sub-zones. If the domain "a" and "d" are not 229 under the control of the same owner, detection of dname loop are 230 impossilbe if "a" and "d" have too many childrens. On the other 231 hand, since the BNAME also maps the owner name itself, we also have 233 a CNAME b; 234 b CNAME c; 235 c CNAME d; 237 For this case, it is easy to detect the name loop. But in the whole, 238 it is not easy to detect the BNAME loop. 240 4.2. Combination of xNAMEs of the different types 242 If there are many different types of xNAME in the chain, it is very 243 difficulty to identify the loop. 245 Different xNAMEs can form a long chain. We can chain together 246 different xNAME records, which may lead to create a xNAME loop. For 247 example, 249 a xNAME b; 250 x xNAME c; 252 if xNAME is DNAME or BNAME, it will creat a many to many mapping; if 253 it is CNAME, it will create a one to one mapping. For the example 254 above, we can divid it into 4 cases: For the case 1: 256 a Single-mapping b; 257 x Single-mapping c; 259 For the case 2: 261 a Multi-mapping b; 262 x Multi-mapping c; 264 For the case 3: 266 a Single-mapping b; 267 x Multi-mapping c; 269 For the case 4: 271 a Multi-mapping b; 272 x Single-mapping c; 274 In the cases above for the example provided in this section, the user 275 may easily detect the loop for the case 1. For other cases, it is 276 very difficult to detect the mapping since Multi-mapping create 277 complex mappling which is not easily detected. 279 There are other more complex examples. But one thing is clear. If 280 Multi-mapping xNAME is involved, it will create the complex of 281 detecting of the loop of xNAME. 283 5. Suggestion of xNAME use 285 If the xNAME chain is formed with single-mapping xNAME only, it can 286 easily check the xNAME loop. But when multi-mapping xNAME is added 287 into the chain, it makes the xNAME detection very difficult. 289 In order to avoid the possible loop, the following suggestions should 290 be considered: 292 1. If there is a xNAME chain, it is better that all names related to 293 xNAME records are under the control of the same owner. 294 2. If there is a xNAME chain, the shortes chain is preferred. 295 3. If there is a xNAME chain, there should have only one multi- 296 mapping xNAME 297 4. Adding a new xNAME to a xNAME chain, the 1, 2 and 3 requirements 298 listed above should be considered to check whether the new xNAME 299 should be configured. 301 6. IANA Considerations 303 IANA is requested to do nothing for this document 305 7. Security Considerations 307 TBD 309 8. Change History 311 [[anchor16: RFC Editor: Please remove this section.]] 313 8.1. draft-yao-dnsop-xNAME-loop: Version 00 315 o xNAME loop detection 317 9. References 318 9.1. Normative References 320 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 321 STD 13, RFC 1034, November 1987. 323 [RFC1035] Mockapetris, P., "Domain names - implementation and 324 specification", STD 13, RFC 1035, November 1987. 326 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 327 Requirement Levels", BCP 14, RFC 2119, March 1997. 329 [RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection", 330 RFC 2672, August 1999. 332 9.2. Informative References 334 [I-D.yao-dnsext-bname] 335 Yao, J., Lee, X., and P. Vixie, "Bundled DNS Name 336 Redirection", draft-yao-dnsext-bname-05 (work in 337 progress), August 2010. 339 [RFC2672bis] 340 Rose, S. and W. Wijngaards, "Update to DNAME Redirection 341 in the DNS", Internet-Draft ietf-dnsext-rfc2672bis-dname- 342 17.txt, 6 2009. 344 Authors' Addresses 346 Jiankang YAO 347 CNNIC 348 No.4 South 4th Street, Zhongguancun 349 Beijing 351 Phone: +86 10 58813007 352 Email: yaojk@cnnic.cn 354 Xiaodong LEE 355 CNNIC 356 No.4 South 4th Street, Zhongguancun 357 Beijing 359 Phone: +86 10 58813020 360 Email: lee@cnnic.cn