idnits 2.17.1 draft-yao-dnsext-identical-resolution-02.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 == 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 (October 25, 2010) is 4932 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'ASCII' is defined on line 568, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 581, but no explicit reference was found in the text == Unused Reference: 'RFC2136' is defined on line 584, but no explicit reference was found in the text == Unused Reference: 'RFC3597' is defined on line 595, but no explicit reference was found in the text == Unused Reference: 'RFC3629' is defined on line 598, but no explicit reference was found in the text == Unused Reference: 'RFC4033' is defined on line 606, but no explicit reference was found in the text == Unused Reference: 'RFC4034' is defined on line 610, but no explicit reference was found in the text == Unused Reference: 'RFC4035' is defined on line 614, but no explicit reference was found in the text == Unused Reference: 'CNAME-DNAME' is defined on line 632, but no explicit reference was found in the text == Unused Reference: 'IDN-TLD-Variants' is defined on line 637, but no explicit reference was found in the text == Unused Reference: 'RFC2672bis' is defined on line 642, but no explicit reference was found in the text == Unused Reference: 'SHADOW' is defined on line 647, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2671 (ref. 'EDNS0') (Obsoleted by RFC 6891) ** Obsolete normative reference: RFC 2672 (Obsoleted by RFC 6672) ** Obsolete normative reference: RFC 3490 (Obsoleted by RFC 5890, RFC 5891) == Outdated reference: A later version (-06) exists of draft-yao-dnsext-bname-01 -- Duplicate reference: RFC2672, mentioned in 'RFC2672bis', was also mentioned in 'RFC2672'. -- Obsolete informational reference (is this intentional?): RFC 2672 (Obsoleted by RFC 6672) Summary: 3 errors (**), 0 flaws (~~), 15 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Woolf 3 Internet-Draft Internet Systems Consortium, Inc. 4 Intended status: Informational J. Yao 5 Expires: April 28, 2011 X. Lee 6 CNNIC 7 October 25, 2010 9 Problem Statement: DNS Resolution of Aliased Names 10 draft-yao-dnsext-identical-resolution-02.txt 12 Abstract 14 This document attempts to describe a set of issues that arises from 15 the desire to treat a set or group of names as "aliases" of each 16 other, "bundled," "variants," or "the same," which is problematic in 17 terms of corresponding behavior for DNS labels. 19 With the emergence of internationalized domain names, among other 20 potential use cases, two or more names that users will regard as 21 having identical meaning will sometimes require corresponding 22 behavior in the DNS. It's not clear how to accommodate these 23 requirements for behavior of such names in DNS resolution; in 24 particular, it's not clear when they are best accommodated in 25 registry practices for generating names for lookup in the DNS, 26 existing DNS protocol elements and behavior, or some set of protocol 27 elements or behavior not yet defined. This document attempts to 28 describe some of these cases and the behavior of some of the possible 29 solutions discussed to date. 31 NOTE: Even more than usual, version -02 of this document is a "work 32 in progress". Additional updates may be expected between the date of 33 this document and the DNSEXT meeting in Beijing, and can be found at 34 http://users.isc.org/~woolf. 36 Status of this Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at http://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on April 28, 2011. 53 Copyright Notice 55 Copyright (c) 2010 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (http://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 This document may contain material from IETF Documents or IETF 69 Contributions published or made publicly available before November 70 10, 2008. The person(s) controlling the copyright in some of this 71 material may not have granted the IETF Trust the right to allow 72 modifications of such material outside the IETF Standards Process. 73 Without obtaining an adequate license from the person(s) controlling 74 the copyright in such materials, this document may not be modified 75 outside the IETF Standards Process, and derivative works of it may 76 not be created outside the IETF Standards Process, except to format 77 it for publication as an RFC or to translate it into languages other 78 than English. 80 Table of Contents 82 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 83 1.1. What this document does . . . . . . . . . . . . . . . . . 5 84 1.2. What this document does not do . . . . . . . . . . . . . . 5 85 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 86 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 6 87 2.1. Registration of Domain Name Variants . . . . . . . . . . . 7 88 2.2. Identical DNS Resolution for Bundled DNS Names . . . . . . 7 89 2.3. Character Variants . . . . . . . . . . . . . . . . . . . . 8 90 2.3.1. An example: Simplified and Traditional Chinese . . . . 8 91 2.3.2. An example: Greek . . . . . . . . . . . . . . . . . . 9 92 2.3.3. An Example: Arabic . . . . . . . . . . . . . . . . . . 9 93 3. Possible Solutions . . . . . . . . . . . . . . . . . . . . . . 9 94 3.1. Mapping or Redirection of Domain Names . . . . . . . . . . 10 95 3.1.1. Mapping itself . . . . . . . . . . . . . . . . . . . . 10 96 3.1.2. Mapping its descendants . . . . . . . . . . . . . . . 10 97 3.1.3. Mapping itself and its descendants . . . . . . . . . . 10 98 3.2. Zone Clone . . . . . . . . . . . . . . . . . . . . . . . . 11 99 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 100 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 101 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 102 7. Change History . . . . . . . . . . . . . . . . . . . . . . . . 13 103 7.1. draft-yao-dnsext-identical-resolution: Version 00 . . . . 13 104 7.2. draft-yao-dnsext-identical-resolution: Version 01 . . . . 13 105 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 106 8.1. Normative References . . . . . . . . . . . . . . . . . . . 13 107 8.2. Informative References . . . . . . . . . . . . . . . . . . 14 108 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 110 1. Introduction 112 As the Internet and the DNS have evolved beyond their original realms 113 of use, a set of needs and expectations has appeared about how DNS 114 labels behave that is informed significantly by common human 115 assumptions about how "names" or "words" work. One aspect of this is 116 the notion or expectation that multiple sets of names may be similar 117 to a human user, and expected to behave "the same" or as "aliases" of 118 one another. The DNS was designed with the implicit expectation that 119 names would be based on ASCII characters, and the "similarity" or 120 "sameness" property doesn't seem to arise terribly often in the names 121 people originally wanted to use in the DNS; thus the requirements of 122 identical resolution of "aliased" or "bundled" names hasn't figured 123 prominently as an attribute that needed to be accommodated in the 124 generation or lookup of DNS names. However, with the standardization 125 of internationalized domain names protocols (ref: IDNA and IDNAbis), 126 more and more internationalized domain name labels [RFC3490] are 127 appearing in DNS zones. In some cases, these labels [RFC3743] are 128 accompanied by the expectation that they are "equivalent" or should 129 behave "the same," often because these labels are derived from names 130 or strings that users consider "the same" in some languages. 131 Accordingly, Internet users hope for such labels to behave in DNS 132 contexts as they expect the corresponding human constructs to behave. 134 The general issues of what "the same" means, or of defining 135 "variants" in human scripts as codified in Unicode (or anywhere else) 136 are well outside the scope of the DNS or the expertise of most of the 137 people who work on it. They are matters for philosophers and 138 applications developers, respectively. However, to the extent that 139 these issues can be specified as involving the resolution of names in 140 the DNS, it's reasonable to describe those expectations and attempt 141 to accomodate them. 143 There is some existing technology defined in the DNS for behavior 144 that can be described as one name behaving "the same" as another. 145 For a single node in the DNS tree, CNAME can be used to map one name 146 as an "alias" to another, "canonical" name. If there is a need to 147 map a subtree of the DNS-- a zone, or a domain and its subdomains-- 148 to another domain, DNAME has been defined to allow this behavior. 149 However, there is no way currently defined to do both, as CNAME is 150 required to be the record at its node in the tree. Behavior that 151 combines their characteristics is not currently defined in the DNS. 153 If existing protocol does not meet the zone administrator's need to 154 be able to treat one label, name, or zone as "the same" as another, 155 there are also administrative mechanisms available for manipulating 156 databases underlying the generation and resolution of DNS names. 157 Registry operators have many mechanisms for working around DNS 158 protocol in order to get behavior they want for names in DNS zones, 159 and management of "aliases" is no exception. However, it is not 160 clear how much of the user and operator requirements for "aliases" 161 can be met by mechanisms for provisioning DNS zones, at acceptable 162 cost. Concerns have been raised about this approach particularly at 163 large scales. 165 1.1. What this document does 167 Attempts to think about "aliases" or similar concepts as applied to 168 the DNS have been difficult, both because use cases have been unclear 169 and because terminology for describing and distinguishing them has 170 not been readily available. This document attempts to provide both 171 brief descriptions of identified use cases, and a rough organization 172 for how to think about behavior in the DNS that might correspond to 173 the requirements derived from them as a way of evaluating proposed 174 solutions. This includes existing and additional possible solutions. 176 As a departure point, we attempt to be rigorous about distinguishing 177 DNS "labels" from "words" (a human construct) and "strings" (which we 178 use here as machine-readable constructs that nonetheless may not 179 conform to DNS label constraints, such as IDNA U-labels). 181 We also review existing constructs (CNAME, DNAME) and proposed new 182 ones ("BNAME," "zone clones"). 184 1.2. What this document does not do 186 This document makes no attempt to solve or even describe 187 "translation" of one name into another in the DNS, which is likely to 188 be impossible. "Translation" in general, or even the particular 189 problem of determining when or why two DNS labels (or even FQDNs) 190 should be considered "the same", are simply not in scope for the DNS 191 protocol. We pre-suppose those decisions are made elsewhere and that 192 the DNS needs to deliver behavior in conformance with that external 193 decision. 195 Accordingly, this document makes no comment on policy regarding when 196 two names are "the same," what restrictions should be placed on their 197 generation or use outside those imposed by the DNS protocol, or the 198 ability of one approach over another to instantiate what a given user 199 regards as "the same" for a language, script, culture, or community. 201 1.3. Terminology 203 All the basic terms used in this specification are defined in the 204 documents [RFC1034], [RFC1035], [RFC2672] and [RFC3490]. 206 We also note that there is a wide variety of terminology in use to 207 describe the issues we attempt to treat in this document, and no 208 consensus on which apply under what conditions. Terms for "a set of 209 domain names that somehow need to be treated as similar" include 210 "bundle," "variants," or "clones". As uniformity of terms is one of 211 the goals of any work on this topic in the DNS, we try not to add to 212 the confusion in the problem statement but can't claim to have 213 finalized a recommendation in early versions of this document. 215 2. Problem Statement 217 From the point of view of the DNS, a number of attributes suggest 218 themselves as important dimensions for evaluating what "the same" 219 might mean. 221 One question is exactly what it is that's to be defined as "the 222 same"? Are the end results to be identical, and if so from what 223 perspective: that of the recursive resolver? The application? The 224 human consumer of content? Is it enough that lookups on the FQDN 225 portion of an email address result in the same A or AAAA records, or 226 does some intermediate mapping need to be maintained between MX 227 records in the resolution chain? What about the FQDN portion of a 228 URL handed back to an application, or in resolution processes that 229 include multiple lookups of records that may include FQDNs? Do there 230 need to be general rules specified for the handling of FQDNs in RDATA 231 of present and future RRtypes? 233 Another question is the behavior of multiple names with respect to 234 one another: is it enough to define one as "canonical" or 235 "preferred," with the others considered as "variants" that are 236 transformed to the "preferred" form? Or is there a real need for 237 multiple names to be "equivalent", interchangeable, with none 238 considered "preferred" over the others? (We note here that no 239 requirement for complete interchangeability or identity has been 240 articulated, except anecdotally, and such equivalence would be 241 extremely difficult to define in the DNS.) 243 In addition, the tree structure of the DNS requires that we consider 244 the behavior of "identical" names across multiple zones in the 245 hierarchy. Are mappings to be maintained in names more than a level, 246 or two, deep? If so, with what characteristics, and what 247 characteristics are required for scalability? 249 A further question arises with respect to how applications should 250 interact with alias-specific DNS behavior. A basic requirement would 251 seem to be "First, do no harm," or in other words, any extensions to 252 DNS protocol in support of the desired "alias" behavior should not 253 interfere with applications that expect to do such interpretation on 254 their own. This concern is based in the expectation that DNS is 255 simple and predictable, operating strictly as infrastructure under 256 the process of creating "the user experience," not as part of it. 258 2.1. Registration of Domain Name Variants 260 The introduction of IDN has provided a forcing function for defining 261 how "variants" might behave as DNS names. It's generally conceded 262 that recognition and careful management of cases where multiple names 263 are associated together as "variants" in the expectation or 264 preference of users are important; without such management of grouped 265 domain names, security risks may be increased and the quality of user 266 experience may be compromised. [RFC3743] developed by JET (Joint 267 Engineering Team) gives one possible solution of how to manage 268 registration of a domain name, intended to be applied to the script 269 and usage common across Chinese, Japanese, and Korean users. 270 [RFC3743] proposed an algorithm which will allocate a group of names, 271 consisting of a domain name and its variants, to the same domain 272 holder. It means that the domain holder will get control of the 273 domain name and its variants. [RFC4290] suggests the practice in 274 [RFC3743] to be used in registrations of internationalized domain 275 names. But [RFC3743] and [RFC4290] do not define how, exactly, these 276 bundles of names are to be treated by the registry or the DNS in 277 order to obtain the desired "identical" behavior. [RFC4690] said 278 that the "variant" model introduced in [RFC3743] and [RFC4290] can be 279 used by a registry to prevent the most negative consequences of 280 possible confusion, by ensuring either that both names are registered 281 to the same party in a given domain or that one of them is completely 282 prohibited. The principles described in [RFC3743], [RFC4290] and 283 [RFC4690] have been accepted by many registries. But the technical 284 details of how to guarantee that a bundle of domain names are 285 "identical" in the DNS remain unspecified. 287 2.2. Identical DNS Resolution for Bundled DNS Names 289 To some extent, the desired behavior can be described: "identical DNS 290 resolution" means that the process of resolving two domain names will 291 end with the same result, in most cases the same IP address. In the 292 history of DNS protocol development, there have been two attempts to 293 specify such "identical resolution" behavior:CNAME[RFC1034] which 294 maps or redirects itself, and DNAME[RFC2672] which maps or redirects 295 its descendants. In the case of bundles or groups of names, however, 296 some operators have asserted they need identical DNS resolution at 297 all levels' domain names, including the domain name itself and its 298 descendants. As alluded to above, registries are left with ad hoc 299 provisioning and database management mechanisms for managing variant 300 names, with some help from existing DNS protocol mechanisms for 301 mapping labels or FQDNs to each other. However, some are finding the 302 existing mechanisms to have unsatisfactory limitations; they are 303 seeking more guidance on the use of existing mechanisms, and perhaps 304 the addition of new ones in the DNS protocol. 306 2.3. Character Variants 308 Many defined scripts as used in many different languages have 309 "character variants" included. There is no uniform definition of 310 variants, and in fact their characteristics differ widely, but it's 311 possible to define some. For example, the definition of variant 312 characters in the JET Guidelines [RFC3743], intended for use with the 313 CJK language/script communities, is roughly this: One conceptual 314 character can be identified with several different Code Points in 315 character sets for computer use. In UNICODE definitions of some 316 scripts, including Han (chinese), some characters can be identified 317 as "compatibility variants" of another character, which usually 318 implies that the first can be remapped to the second without the loss 319 of any meaning. In this document, variant characters are two or more 320 characters that may be similar in appearance or identical in meaning 321 (similarity in appearance is not required by the definition but often 322 occurs). 324 With the introduction of IDNs in the DNS, perhaps most prominently in 325 the root zone, decisions about how to deal with IDN variants is a 326 significant challenge ahead of us. We describe here a couple of 327 examples, Chinese and Greek; [STW: ....and additional cases (Arabic, 328 Cyrillic, etc.)should be described in future versions by experts in 329 those scripts and languages]. 331 2.3.1. An example: Simplified and Traditional Chinese 333 For example, if the IDN TLD "China"(U+4E2D U+56FD) and its variant 334 (U+4E2D U+570B) are put into the root, the first one (U+4E2D U+56FD) 335 can be considered the "original" IDN TLD and the second one (U+4E2D 336 U+570B) can be considered the IDN TLD "variant". Ideally, it should 337 be possible to treat the original IDN TLD and its IDN TLD variant as 338 "identical" for purposes of DNS resolution, in a way similar to the 339 case mapping most DNS users take for granted, in which the uppercase 340 "A" is the variant of lowercase "a". For example, the string ".COM" 341 can be considered a variant of ".com", and the corresponding DNS 342 labels are treated as identical. However, for the historical reasons 343 already discussed, and technical reasons having to do with the 344 underpinnings of the IDNAbis protocol (ref: IDNAbis rationale), 345 there's no generalization of the "case" mapping available for 346 situations where it might be useful for IDNs. In addition, it's 347 perilous because DNS rules around "case insensitivity" and "case 348 preservation" are not intuitively consistent. 350 At this writing, four Chinese script IDN TLDs are in the root, 351 including two pairs comprising a Traditional Chinese name and its 352 Simplified counterpart, which should allow future versions of this 353 document to include those operators' experience of managing 354 maintenance of those names as "the same." 356 2.3.2. An example: Greek 358 In Greek, almost every word has the "tonos" accent sign, but where it 359 is placed (on which character) can vary. Further, some words end in 360 a final sigma, which is represented differently to sigma appearing 361 elsewhere in the word. If a registry wishes to be able to enforce 362 the association among all of the domain names that correspond to a 363 "word" in Greek, with all its possible Unicode strings, some 364 mechanism must be used to enumerate the "variant" names and tie them 365 together. This makes sense from the human factors perspective, as 366 depending on how the user types something, results may include a 367 different domain to what was expected, although the user may have the 368 firm belief that "the same word" was input in multiple cases. 370 As an example, the domain names "xn--0xadhj4a.gr" and "xn-- 371 0xaafjl.gr" appear to a native speaker/reader of Greek to represent 372 "the same word," in a sense very much like the case insensitivity 373 that native users of Latin script take for granted in the DNS. 375 2.3.3. An Example: Arabic 377 [STW: [to be added] 379 3. Possible Solutions 381 Currently, there are several possible mechanisms to support identical 382 DNS resolution of "bundled" or "variant" names as "aliases" in the 383 DNS. Existing mechanisms in the DNS include CNAME and DNAME. In 384 addition, as described briefly above, registry operators have a great 385 many techniques for applying policy to what names can be registered, 386 and provisioning technology to how they are instantiated in the DNS, 387 in support of keeping "variant" names behaving similarly to each 388 other, or in preventing the use of such variants as might be 389 considered confusing or dangerous. 391 In addition, there are new proposals for DNS protocol to support 392 "aliases" in the DNS as part of the desired behavior of "variant" 393 names: Names direction[BNAME], and "Zone clone". 395 All of the solutions have their advantages and disadvantages. In 396 particular, there are a couple of limitations they all share. Every 397 mechanism existing or proposed to support "aliases" in the DNS 398 requires that one name be designated as the "canonical" name 399 ("preferred" in the terminology of the JET variant mechanism) and any 400 others bundled with it are to be considered "variants" or "aliases". 401 The only known way to enforce a symmetrical or equivalent association 402 is via careful registry provisioning within and across domains. In 403 addition, the different "alias" mechanisms differ in subtle ways that 404 have to be carefully reviewed against the desired behavior of the DNS 405 in support of different types of "variants". 407 3.1. Mapping or Redirection of Domain Names 409 3.1.1. Mapping itself 411 It was recognized as part of the original specification of the DNS 412 that a host can have many names; in fact this expectation predates 413 the DNS, referring to the earlier specification of host names. In 414 the simplest case for "aliases", Internet users need these multiple 415 names to be resolved to the same IP address by a DNS server. The 416 CNAME record [RFC1034], where "CNAME" is an abbreviation for 417 "Canonical Name", is a way to designate aliases of the "real" or 418 canonical name of a host. In some cases, CNAME can be used to 419 produce the necessary association a bundle of variant domain names. 420 But the CNAME only maps itself, not its descendants; in fact it is 421 defined to not have descendants, as it is the only name at a node in 422 the DNS tree and can't exist at the same name as delegation. In the 423 case of IDN variants, however, it is often desirable that the name 424 map both itself and its descendants. 426 3.1.2. Mapping its descendants 428 In order to maintain the address-to-name mappings in a context of 429 network renumbering, a DNAME record or Delegation Name record defined 430 by [RFC2672] was invented to create an alias for all its subdomains. 431 In contrast, the CNAME record creates an alias only of a single name 432 (and not of its subdomains). As with the CNAME record, the DNS 433 lookup will continue by retrying the lookup with the new name. If a 434 DNS resolver sends a query without EDNS[EDNS0], or with EDNS version 435 0, then a name server synthesizes a CNAME record to simulate the 436 semantics of the DNAME record. A DNAME record is very much like the 437 CNAME record, but while the CNAME record only applies for one name, 438 with a DNAME record one can create aliases for all the records for 439 its subdomain. 441 3.1.3. Mapping itself and its descendants 443 Bundling of "variant" strings or names as domain names, possibly 444 along with other use cases not yet identified, require the ability to 445 map a whole tree of the domain space to another domain. The current 446 DNS protocols do not support this function. A new DNS resource 447 record [BNAME] has been proposed to deal with this problem. 449 The advantage of BNAME is that it would enable a class of "aliasing" 450 behavior that some operators find desirable, particularly in 451 preference to some of the provisioning overhead they describe having 452 to deploy to support potentially large numbers of "bundles" of 453 variants at multiple levels of the DNS tree. The disadvantage is 454 that it may not provide the behavior people really want while 455 requiring the time and resources to code and deploy any new DNS 456 facility. 458 Alternatively, a proposal has been made that would leave CNAME as 459 already specified, but eliminating the constraint that a CNAME must 460 be alone at a node in the DNS tree. This would avoid any coding and 461 deployment overhead associated with new RRtypes, while obtaining the 462 desired behavior. Concerns expressed about it, however, include the 463 possible (but not yet specified) effort required for backwards 464 compatibility to avoid harm to implementations that expect, and use, 465 the old behavior. 467 3.2. Zone Clone 469 The proposal of "zone clone" or "dns shadow", is an alternative 470 solution for a higher level of support than the DNS currently 471 provides for "alias" behavior across zones. In this scheme, a new 472 RRtype, SHADOW, is specified; it can exist at a zone apex and can be 473 used to define "clones" or "shadows" of the zone content so that 474 records in the zone are reachable via lookups from multiple 475 delegations. This mechanism varies fundamentally from CNAME/DNAME/ 476 BNAME in that it creates a local copy on each cooperating 477 authoritative server that has the original zone, reachable by the 478 names specified in the SHADOW RR. Its scope, then, is the zone as 479 maintained by an authoritative server rather than a single RRset 480 (even one corresponding to a delegation). 482 This scheme has the advantage that it allows a SHADOW zone to be used 483 in all the same contexts as the canonical or underlying zone, 484 including contexts where a CNAME or DNAME (or, presumably, a BNAME) 485 cannot appear, such as in the RDATA of certain RRtypes. Of the 486 proposed DNS protocol mechanisms, it probably comes closest to the 487 behavior some have requested as "equivalence," where none of the 488 bundled or SHADOW names is canonical or preferred over the others. 489 It does implicate an unknown level of effort to implement and 490 support. 492 4. IANA Considerations 494 There are no obvious IANA considerations in this memo; we reiterate 495 that the determination of which names are to be considered "the same" 496 is explicitly out of scope. 498 5. Security Considerations 500 [STW: Looking for examples for this section.] 502 Unsolved issues that will have to be considered in the definition of 503 what "the same" means for the DNS include the implications for 504 DNSSEC, and whether "identical" resolution includes DNSSEC validation 505 in the expected "identical" behavior. 507 Another area of possible peril includes SSL certificates, "Host" 508 headers as seen by web servers, and other security-relevant data 509 often associated with domain names. It will have to be considered 510 whether, and how, the "sameness" property maps into the expected 511 behavior of security-related protocols that use domain names, 512 particularly given that it's unlikely that all operators will ever 513 use the same set of constructs (whether in the DNS or elsewhere) to 514 signal whether different "names" are "the same" for purposes of the 515 function of a particular application or protocol. 517 In addition, there is a large cluster of security risks at the user 518 and application levels that motivate significant portions of the 519 interest in what it means to treat a set of names as "aliases" of 520 each other. One set of issues is around the expectation that two 521 strings are seen as "different" by the user in some obvious way (such 522 as visually) but need to be treated as "the same". The potential for 523 user confusion and subversion is not hard to imagine in cases where 524 two visually distinct strings are nonetheless likely to be expected 525 by the user to behave "the same" in some functional way. This is the 526 case we have attempted to address here. 528 There is a separate but complementary set of issues that arise around 529 cases where strings that look "the same" should nonetheless be 530 treated as different-- the so-called "confusing visual similarity" 531 problem. The easy example is substituting the Unicode codepoint for 532 a character in one script, or a string of them, for the Unicode 533 codepoints for similar-looking characters in an altogether different 534 script. This has a different set of potential risks to users, and 535 has not been discussed here. It's often closely related to the 536 "alias" issue we have attempted to deal with, however, which poses 537 risks of its own to analysis of the either subject. 539 6. Acknowledgements 541 Most of the ideas here and much of the text is taken from discussions 542 on the DNSEXT and DNSOP WG mailing lists. Particular help is 543 acknowledged from the authors of the proposed solutions drafts, and 544 from the many contributors to the IDNAbis work and its underpinnings. 545 Special thanks at the intersection of DNS and IDNAbis is owed to 546 Patrik Faltstrom, Cary Karp, John Klensin, Vaggelis Segredakis, and 547 Andrew Sullivan for their patient explanations. 549 7. Change History 551 [[anchor20: RFC Editor: Please remove this section.]] 553 7.1. draft-yao-dnsext-identical-resolution: Version 00 555 o Domain Name Identical Resolution Problem Statement (initial 556 attempt) 558 7.2. draft-yao-dnsext-identical-resolution: Version 01 560 o Expanded introduction 561 o Added Greek example 562 o Added some detail to descriptions of proposed solutions 564 8. References 566 8.1. Normative References 568 [ASCII] American National Standards Institute (formerly United 569 States of America Standards Institute), "USA Code for 570 Information Interchange", ANSI X3.4-1968, 1968. 572 [EDNS0] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", 573 RFC 2671, August 1999. 575 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 576 STD 13, RFC 1034, November 1987. 578 [RFC1035] Mockapetris, P., "Domain names - implementation and 579 specification", STD 13, RFC 1035, November 1987. 581 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 582 Requirement Levels", BCP 14, RFC 2119, March 1997. 584 [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, 585 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 586 RFC 2136, April 1997. 588 [RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection", 589 RFC 2672, August 1999. 591 [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, 592 "Internationalizing Domain Names in Applications (IDNA)", 593 RFC 3490, March 2003. 595 [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record 596 (RR) Types", RFC 3597, September 2003. 598 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 599 10646", RFC 3629, November 2003. 601 [RFC3743] Konishi, K., Huang, K., Qian, H., and Y. Ko, "Joint 602 Engineering Team (JET) Guidelines for Internationalized 603 Domain Names (IDN) Registration and Administration for 604 Chinese, Japanese, and Korean", RFC 3743, April 2004. 606 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 607 Rose, "DNS Security Introduction and Requirements", 608 RFC 4033, March 2005. 610 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 611 Rose, "Resource Records for the DNS Security Extensions", 612 RFC 4034, March 2005. 614 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 615 Rose, "Protocol Modifications for the DNS Security 616 Extensions", RFC 4035, March 2005. 618 [RFC4290] Klensin, J., "Suggested Practices for Registration of 619 Internationalized Domain Names (IDN)", RFC 4290, 620 December 2005. 622 [RFC4690] Klensin, J., Faltstrom, P., Karp, C., and IAB, "Review and 623 Recommendations for Internationalized Domain Names 624 (IDNs)", RFC 4690, September 2006. 626 8.2. Informative References 628 [BNAME] Yao, J., Lee, X., and P. Vixie, "Bundle DNS Name 629 Redirection", draft-yao-dnsext-bname-01.txt (work in 630 progress), 12 2009. 632 [CNAME-DNAME] 633 Sury, O., "CNAME+DNAME Name Redirection", 634 draft-sury-dnsext-cname-dname-00.txt (work in progress), 635 4 2010. 637 [IDN-TLD-Variants] 638 Yao, J. and X. Lee, "IDN TLD Variants Implementation 639 Guideline", draft-yao-dnsop-idntld-implementation-01.txt 640 (work in progress), 11 2009. 642 [RFC2672bis] 643 Rose, S. and W. Wijngaards, "Update to DNAME Redirection 644 in the DNS", Internet-Draft ietf-dnsext-rfc2672bis-dname- 645 17.txt, 6 2009. 647 [SHADOW] Vixie, P., "Use of DNS to Carry Configuration Metadata 648 Concerning Automatic Replication of Zones", 649 draft-vixie-dnsext-dnsshadow-00.txt (work in progress), 650 2 2010. 652 Authors' Addresses 654 Suzanne Woolf 655 Internet Systems Consortium, Inc. 656 950 Charter St. 657 Redwood City, CA 94063 659 Phone: +1 650 423 1333 660 Email: woolf@isc.org 662 Jiankang YAO 663 CNNIC 664 No.4 South 4th Street, Zhongguancun 665 Beijing 667 Phone: +86 10 58813007 668 Email: yaojk@cnnic.cn 670 Xiaodong LEE 671 CNNIC 672 No.4 South 4th Street, Zhongguancun 673 Beijing 675 Phone: +86 10 58813020 676 Email: lee@cnnic.cn