idnits 2.17.1 draft-ietf-dnsext-aliasing-requirements-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 == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == 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 (February 22, 2011) is 4783 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'ASCII' is defined on line 808, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 821, but no explicit reference was found in the text == Unused Reference: 'RFC2136' is defined on line 824, but no explicit reference was found in the text == Unused Reference: 'RFC3597' is defined on line 835, but no explicit reference was found in the text == Unused Reference: 'RFC3629' is defined on line 838, but no explicit reference was found in the text == Unused Reference: 'RFC4033' is defined on line 846, but no explicit reference was found in the text == Unused Reference: 'RFC4034' is defined on line 850, but no explicit reference was found in the text == Unused Reference: 'RFC4035' is defined on line 854, but no explicit reference was found in the text == Unused Reference: 'CNAME-DNAME' is defined on line 872, but no explicit reference was found in the text == Unused Reference: 'IDN-TLD-Variants' is defined on line 877, but no explicit reference was found in the text == Unused Reference: 'RFC2672bis' is defined on line 882, but no explicit reference was found in the text == Unused Reference: 'SHADOW' is defined on line 887, 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 (~~), 16 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 X. Lee 5 Expires: August 26, 2011 CNNIC 6 February 22, 2011 8 Problem Statement: DNS Resolution of Aliased Names 9 draft-ietf-dnsext-aliasing-requirements-00.txt 11 Abstract 13 This document attempts to describe a set of issues that arises from 14 the desire to treat a set or group of names as "aliases" of each 15 other, "bundled," "variants," or "the same," which is problematic in 16 terms of corresponding behavior for DNS labels and FQDNs. 18 With the emergence of internationalized domain names, among other 19 potential use cases, two or more names that users will regard as 20 having identical meaning may sometimes require corresponding behavior 21 in the underlying infrastructure, possibly in the DNS itself. It's 22 not clear how to accommodate this required behavior of such names in 23 DNS resolution; in particular, it's not clear when they are best 24 accommodated in registry practices for generating names for lookup in 25 the DNS, existing DNS protocol elements and behavior, existing 26 application-layer mechanisms and practices, 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 Status of this Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on August 26, 2011. 48 Copyright Notice 49 Copyright (c) 2011 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 This document may contain material from IETF Documents or IETF 63 Contributions published or made publicly available before November 64 10, 2008. The person(s) controlling the copyright in some of this 65 material may not have granted the IETF Trust the right to allow 66 modifications of such material outside the IETF Standards Process. 67 Without obtaining an adequate license from the person(s) controlling 68 the copyright in such materials, this document may not be modified 69 outside the IETF Standards Process, and derivative works of it may 70 not be created outside the IETF Standards Process, except to format 71 it for publication as an RFC or to translate it into languages other 72 than English. 74 Table of Contents 76 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 77 1.1. What this document does . . . . . . . . . . . . . . . . . 5 78 1.2. What this document does not do . . . . . . . . . . . . . . 5 79 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 80 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 6 81 2.1. Registration of Domain Name Variants . . . . . . . . . . . 7 82 2.2. Identical DNS Resolution for Bundled DNS Names . . . . . . 8 83 2.3. Character Variants . . . . . . . . . . . . . . . . . . . . 8 84 2.3.1. An example: Simplified and Traditional Chinese . . . . 9 85 2.3.2. An example: Greek . . . . . . . . . . . . . . . . . . 9 86 2.3.3. An Example: Arabic . . . . . . . . . . . . . . . . . . 10 87 2.4. Use of Variants . . . . . . . . . . . . . . . . . . . . . 10 88 3. Operational Considerations . . . . . . . . . . . . . . . . . . 11 89 3.1. Zone Provisioning and Authority Servers . . . . . . . . . 11 90 3.1.1. Provisioning of 'aliases' in the registry . . . . . . 11 91 3.1.2. Impact of special mechanisms . . . . . . . . . . . . . 12 92 3.2. Recursive Resolvers . . . . . . . . . . . . . . . . . . . 12 93 3.3. Applications . . . . . . . . . . . . . . . . . . . . . . . 13 94 4. Proposed Requirements . . . . . . . . . . . . . . . . . . . . 14 95 5. Possible Solutions . . . . . . . . . . . . . . . . . . . . . . 14 96 5.1. Mapping or Redirection of Domain Names . . . . . . . . . . 15 97 5.1.1. Mapping itself . . . . . . . . . . . . . . . . . . . . 15 98 5.1.2. Mapping its descendants . . . . . . . . . . . . . . . 15 99 5.1.3. Mapping itself and its descendants . . . . . . . . . . 16 100 5.2. Zone Clone . . . . . . . . . . . . . . . . . . . . . . . . 16 101 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 102 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 103 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 104 9. Change History . . . . . . . . . . . . . . . . . . . . . . . . 18 105 9.1. draft-yao-dnsext-identical-resolution: Version 00 . . . . 18 106 9.2. draft-yao-dnsext-identical-resolution: Version 01 . . . . 18 107 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 108 10.1. Normative References . . . . . . . . . . . . . . . . . . . 18 109 10.2. Informative References . . . . . . . . . . . . . . . . . . 20 110 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 112 1. Introduction 114 As the Internet and the DNS have evolved beyond their original realms 115 of use, a set of needs and expectations has appeared about how DNS 116 labels behave that is informed significantly by common human 117 assumptions about how "names" or "words" work. One aspect of this is 118 the notion or expectation that multiple sets of names may be similar 119 to a human user, and expected to behave "the same" or as "aliases" of 120 one another, across multiple services and interactions. The DNS was 121 designed with the implicit expectation that names would be based on 122 ASCII characters, and the "similarity" or "sameness" property doesn't 123 seem to arise terribly often in the names people originally wanted to 124 use in the DNS; thus the requirements of identical resolution of 125 "aliased" or "bundled" names hasn't figured prominently as an 126 attribute that needed to be accommodated in the generation or lookup 127 of DNS names. However, with the standardization of internationalized 128 domain names protocols (ref: IDNA and IDNAbis), more and more 129 internationalized domain name labels [RFC3490] are appearing in DNS 130 zones. In some cases, these labels [RFC3743] are accompanied by the 131 expectation that they are "equivalent" or should behave "the same," 132 often because these labels are derived from names or strings that 133 users consider "the same" in some languages. Accordingly, Internet 134 users hope for such labels to behave in DNS contexts as they expect 135 the corresponding human constructs to behave, regardless of the 136 specific service (smtp, http, etc.) involved.. 138 The general issues of what "the same" means, or of defining 139 "variants" in human scripts as codified in Unicode (or anywhere else) 140 are well outside the scope of the DNS or the expertise of most of the 141 people who work on it. They are matters for philosophers and 142 applications developers, respectively. However, to the extent that 143 these issues can be specified as involving the resolution of names in 144 the DNS, it's reasonable to describe those expectations and attempt 145 to accommodate them. 147 There is some existing technology defined in the DNS for behavior 148 that can be described as one name behaving "the same" as another. 149 For a single node in the DNS tree, CNAME can be used to map one name 150 as an "alias" to another, "canonical" name. If there is a need to 151 map a subtree of the DNS-- a zone, or a domain and its subdomains-- 152 to another domain, DNAME has been defined to allow this behavior. 153 However, there is no way currently defined to do both, as CNAME is 154 required to be the sole record at its node in the tree. Behavior 155 that combines the characteristics of CNAME and DNAME is not currently 156 defined in the DNS. 158 If existing protocol does not meet the zone administrator's need to 159 be able to treat one label, name, or zone as "the same" as another, 160 there are also administrative mechanisms available for manipulating 161 databases underlying the generation and resolution of DNS names. 162 Registry operators have many mechanisms for working around DNS 163 protocol in order to get behavior they want for names in DNS zones, 164 and management of "aliases" is no exception. However, it is not 165 clear how much of the user and operator requirements for "aliases" 166 can be met by mechanisms for provisioning DNS zones, at acceptable 167 cost. Concerns have been raised about this approach particularly at 168 large scales and there is a need both to provision possibly 169 exponential numbers of domains and then to audit them for compliance 170 with parent registry policy. 172 1.1. What this document does 174 Attempts to think about "aliases" or similar concepts as applied to 175 the DNS have been difficult, both because use cases have been unclear 176 and because terminology for describing and distinguishing them has 177 not been readily available. This document attempts to provide both 178 brief descriptions of identified use cases, and a rough organization 179 for how to think about behavior in the DNS that might correspond to 180 the requirements derived from them as a way of evaluating proposed 181 solutions. This includes existing and additional possible solutions, 182 from the perspective of both DNS (authoritative server, resolver, and 183 client) and application needs. 185 As a departure point, we attempt to be rigorous about distinguishing 186 DNS "labels" from "words" (a human construct) and "strings" (which we 187 use here as machine-readable constructs that nonetheless may not 188 conform to DNS label constraints, such as IDNA U-labels). The 189 distinctions among what humans type or see, what applications use, 190 and what DNS stores and resolves are sometimes subtle but 191 particularly important. 193 A list of broad requirements is proposed for any DNS protocol changes 194 that might be undertaken. 196 We also review existing constructs (CNAME, DNAME) and proposed new 197 ones ("BNAME," "zone clones") against the proposed requirements. 199 1.2. What this document does not do 201 This document makes no attempt to solve or even describe 202 "translation" of one name into another in the DNS, which is likely to 203 be impossible. "Translation" in general, or even the particular 204 problem of determining when or why two DNS labels (or even FQDNs) 205 should be considered "the same", is simply not in scope for the DNS 206 protocol. We pre-suppose those decisions are made elsewhere and that 207 the DNS needs to deliver behavior in conformance with that external 208 decision. In particular, we're talking about creating a property or 209 association among a set of DNS names as "sameness" or "alias-of", but 210 the correspondence between that set and any set of human- or 211 application-visible strings is created outside of the DNS database 212 and protocol. 214 Accordingly, this document makes no comment on policy regarding when 215 two names are "the same," what restrictions should be placed on their 216 generation or use outside those imposed by the DNS protocol, or the 217 ability of one approach over another to instantiate what a given user 218 regards as "the same" for a language, script, culture, community, 219 application, encoding, or purpose. 221 1.3. Terminology 223 All the basic terms used in this specification are defined in the 224 documents [RFC1034], [RFC1035], [RFC2672] and [RFC3490]. 226 We also note that there is a wide variety of terminology in use to 227 describe the issues we attempt to treat in this document, and no 228 consensus on which apply under what conditions. Terms for "a set of 229 domain names that somehow need to be treated as similar" include 230 "bundle," "variants," or "clones". As uniformity of terms is one of 231 the goals of any work on this topic in the DNS, we try not to add to 232 the confusion in the problem statement but can't claim to have 233 finalized a recommendation in early versions of this document. 235 2. Problem Statement 237 From the point of view of the DNS, a number of attributes suggest 238 themselves as important dimensions for evaluating what "the same" 239 might mean. 241 One question is exactly what it is that's to be defined as "the 242 same"? Are the end results to be identical, and if so from what 243 perspective: that of the recursive resolver? The application? The 244 human consumer of content? Is it enough that lookups on the FQDN 245 portion of an email address result in the same A or AAAA records, or 246 does some intermediate mapping need to be maintained between MX 247 records in the resolution chain? What about the FQDN portion of a 248 URL handed back to an application, or in resolution processes that 249 include multiple lookups of records that may include FQDNs? Do there 250 need to be general rules specified for the handling of FQDNs in RDATA 251 of present and future RRtypes? 253 Another question is the behavior of multiple names with respect to 254 one another: is it enough to define one as "canonical" or 255 "preferred," with the others considered as "variants" that are 256 transformed to the "preferred" form? Or is there a real need for 257 multiple names to be "equivalent", interchangeable, with none 258 considered "preferred" over the others? (We note here that no 259 requirement for complete interchangeability or identity has been 260 articulated, except anecdotally, and such equivalence would be 261 extremely difficult to define in the DNS.) 263 In addition, the tree structure of the DNS requires that we consider 264 the behavior of "identical" names across multiple zones in the 265 hierarchy. Are mappings to be maintained in names more than a level, 266 or two, deep? If so, with what characteristics, and what 267 characteristics are required for scalability? 269 A further question arises with respect to how applications should 270 interact with alias-specific DNS behavior. A basic requirement would 271 seem to be "First, do no harm," or in other words, any extensions to 272 DNS protocol in support of the desired "alias" behavior should not 273 interfere with applications that expect to do such interpretation on 274 their own. This concern is based in the expectation that DNS is 275 simple and predictable, operating strictly as infrastructure under 276 the process of creating "the user experience," not as part of it. 278 2.1. Registration of Domain Name Variants 280 The introduction of IDN has provided a forcing function for defining 281 how "variants" might behave as DNS names. It's generally conceded 282 that recognition and careful management of cases where multiple names 283 are associated together as "variants" in the expectation or 284 preference of users are important; without such management of grouped 285 domain names, security risks may be increased and the quality of user 286 experience may be compromised. [RFC3743] developed by JET (Joint 287 Engineering Team) gives one possible solution of how to manage 288 registration of a domain name, intended to be applied to the script 289 and usage common across Chinese, Japanese, and Korean users. 290 [RFC3743] proposed an algorithm which will allocate a group of names, 291 consisting of a domain name and its variants, to the same domain 292 holder. It means that the domain holder will get control of the 293 domain name and its variants. [RFC4290] suggests the practice in 294 [RFC3743] to be used in registrations of internationalized domain 295 names. But [RFC3743] and [RFC4290] do not define how, exactly, these 296 bundles of names are to be treated by the registry or the DNS in 297 order to obtain the desired "identical" behavior. [RFC4690] said 298 that the "variant" model introduced in [RFC3743] and [RFC4290] can be 299 used by a registry to prevent the most negative consequences of 300 possible confusion, by ensuring either that both names are registered 301 to the same party in a given domain or that one of them is completely 302 prohibited. The principles described in [RFC3743], [RFC4290] and 304 [RFC4690] have been accepted by many registries. But the technical 305 details of how to guarantee that a bundle of domain names are 306 "identical" in the DNS remain unspecified. 308 2.2. Identical DNS Resolution for Bundled DNS Names 310 To some extent, the desired behavior can be described: "identical DNS 311 resolution" means that the process of resolving two domain names will 312 end with the same result, in most cases the same IP address. In the 313 history of DNS protocol development, there have been two attempts to 314 specify such "identical resolution" behavior:CNAME[RFC1034] which 315 maps or redirects itself, and DNAME[RFC2672] which maps or redirects 316 its descendants. In the case of bundles or groups of names, however, 317 some operators have asserted they need identical DNS resolution at 318 all levels' domain names, including the domain name itself and its 319 descendants. As alluded to above, registries are left with ad hoc 320 provisioning and database management mechanisms for managing variant 321 names, with some help from existing DNS protocol mechanisms for 322 mapping labels or FQDNs to each other. However, some are finding the 323 existing mechanisms to have unsatisfactory limitations; they are 324 seeking more guidance on the use of existing mechanisms, and perhaps 325 the addition of new ones in the DNS protocol. 327 2.3. Character Variants 329 Many defined scripts as used in many different languages have 330 "character variants" included. There is no uniform definition of 331 variants, and in fact their characteristics differ widely, but it's 332 possible to define some. For example, the definition of variant 333 characters in the JET Guidelines [RFC3743], intended for use with the 334 CJK language/script communities, is roughly this: One conceptual 335 character can be identified with several different Code Points in 336 character sets for computer use. In UNICODE definitions of some 337 scripts, including Han (chinese), some characters can be identified 338 as "compatibility variants" of another character, which usually 339 implies that the first can be remapped to the second without the loss 340 of any meaning. In this document, variant characters are two or more 341 characters that may be similar in appearance or identical in meaning 342 (similarity in appearance is not required by the definition but often 343 occurs). 345 With the introduction of IDNs in the DNS, perhaps most prominently in 346 the root zone, decisions about how to deal with IDN variants is a 347 significant challenge ahead of us. We describe here a couple of 348 examples, Chinese and Greek; comparable situations exist in Arabic, 349 Cyrillic, and others. 351 2.3.1. An example: Simplified and Traditional Chinese 353 For example, the IDN TLD "China"(U+4E2D U+56FD) and its variant 354 (U+4E2D U+570B) are in the root today. The first one (U+4E2D U+56FD) 355 can be considered the "original" IDN TLD and the second one (U+4E2D 356 U+570B) can be considered the IDN TLD "variant". Ideally, it should 357 be possible to treat the original IDN TLD and its IDN TLD variant as 358 "identical" for purposes of DNS resolution, in a way similar to the 359 case mapping most DNS users take for granted, in which the uppercase 360 "A" is the variant of lowercase "a". For example, the string ".COM" 361 can be considered a variant of ".com", and the corresponding DNS 362 labels are treated as identical. However, for the historical reasons 363 already discussed, and technical reasons having to do with the 364 underpinnings of the IDNAbis protocol (ref: IDNAbis rationale), 365 there's no generalization of the "case" mapping available for 366 situations where it might be useful for IDNs. In addition, it's 367 perilous because DNS rules around "case insensitivity" and "case 368 preservation" are not intuitively consistent; for example, case 369 folding is done for comparison but not for compression. 371 At this writing, four Han script IDN TLDs are in the root, including 372 two pairs comprising a Traditional Chinese name and its Simplified 373 counterpart. These operators will, in an ideal world, be able to 374 share some operational experience around implementation of registry 375 policy regarding managing multiple DNS trees as "the same" 377 2.3.2. An example: Greek 379 In Greek, almost every word has the "tonos" accent sign, but where it 380 is placed (on which character) can vary. Further, some words end in 381 a final sigma, which is represented differently to sigma appearing 382 elsewhere in the word. If a registry wishes to be able to enforce 383 the association among all of the domain names that correspond to a 384 "word" in Greek, with all its possible Unicode strings, some 385 mechanism must be used to enumerate the "variant" names and tie them 386 together. This makes sense from the human factors perspective, as 387 depending on how the user types something, results may include a 388 different domain to what was expected, although the user may have the 389 firm belief that "the same word" was input in multiple cases. 391 As an example, the domain names "xn--0xadhj4a.gr" and "xn-- 392 0xaafjl.gr" appear to a native speaker/reader of Greek to represent 393 "the same word," in a sense very much like the case insensitivity 394 that native users of Latin script take for granted in the DNS. 396 2.3.3. An Example: Arabic 398 [STW: [to be added] 400 2.4. Use of Variants 402 It's reasonable to pose the question at this point, without 403 necessarily being able to answer it yet, of what is the ideal or 404 intended impact of solving the issue identified so far for registries 405 on applications and end users. Ultimately, simplifying the 406 provisioning side may result in the same semantics as we have today 407 for zones maintained in parallel but for less work. However, we 408 later assert a proposed requirement that synthesizing the same record 409 as a query would have obtained from an enumerated parallel tree isn't 410 enough-- that the property of association or "sameness" we're 411 creating with specific mechanisms needs to be useful in some specific 412 way to the consumer of the data. 414 The trigger for raising the questions discussed here is based in user 415 expectations that one name, in certain circumstances to be determined 416 and somehow encoded by humans, can be treated as interchangeable with 417 another with regards to a particular context or activity, with 418 resolution of domain names as part of the context or activity. 419 However, it's useful to note here that satisfying that set of user 420 expectations may or may not reasonably be done in the DNS, wholly or 421 in part. 423 There are two arguments for placing functionality that links one name 424 to another as "the same" in the DNS. Their validity is not yet 425 determined, but they amount to: 426 1. The expectation that two or more names be "the same" is often 427 expressed as a desire to register the associated names as a 428 "bundle" or otherwise link them as domain names. This is because 429 the domain name in a URL or email address is often presented to 430 the user as semantically meaningful, based on strings used to 431 derive DNS labels-- proper names, "words," etc. This brings such 432 concerns to the attention of providers of domain names, and 433 suggests at least exploring how to answer the question near where 434 it's asked-- i.e. the registry. 435 2. The desire for names on the Internet to act like words is often 436 service-independent; users want to be able to use identical 437 strings in the course of invoking multiple services that seem to 438 be related, such as going to a webpage and then sending email to 439 an address in "the same" domain (probably an FQDN). It's been 440 noted that people are very comfortable with a certain amount of 441 fuzziness about "alternative spellings" and assorted other 442 variations within the notion of "sameness", but they nonetheless 443 often want such an association to exist. In cases where a set of 444 variant strings is parseable in the application, has 445 corresponding A-labels that can be looked up in the DNS, etc. but 446 only a subset can be typed on the user's input device or rendered 447 on the user's screen, the association may be necessary to the 448 successful completion of the activity the user is attempting. 449 This argues in turn for some mechanism that is not dependent on 450 the specific service, protocol, or application involved, since 451 leaving it up to service-specific mechanisms, or conventions in 452 the use of DNS records or other mechanisms not really intended 453 for the purpose, leads to confusion and inconsistency. 455 3. Operational Considerations 457 Any change to a mature infrastructure protocol such as DNS needs to 458 be informed by consideration of the tradeoffs among providing the 459 associated service, using the service, and possibly conflicting means 460 of offering comparable functionality. In the case of DNS, this 461 requires that we look at provisioning (populating zones and the 462 mechanics of authority servers responding to queries), service by 463 intermediate and client resolvers, and related capabilities provided 464 with existing facilities in the DNS and in applications. 466 3.1. Zone Provisioning and Authority Servers 468 The initial motivation for discussion of support for aliases in the 469 DNS was provided by operators of top-level domain (TLD) registries. 470 The problem facing them lies in scaling the provision of "bundles" of 471 names that users expect to be treated "the same", as in the examples 472 previously described. 474 3.1.1. Provisioning of 'aliases' in the registry 476 The most obvious way to provision multiple names as "the same" is to 477 delegate each separately, and then maintain the contents of the 478 delegated zones together, from the same backend database or by some 479 similar mechanism. This has the advantage of requiring no new 480 technology; it can be done, and is done today, entirely with 481 provisioning logic and registry policy. 483 However, it doubles the work and the number of records required. If 484 provisioning isn't done carefully, errors can arise, leaving 485 inconsistencies. And provisioning multiple trees does nothing to 486 link the resulting names directly; there is no property of 487 "association" or isomorphism created in the DNS that corresponds to 488 user or application expectations for "sameness". There is no way to 489 tell, from resolving a name in one tree, that it's part of a set or 490 bundle of related names. 492 Separate provisioning also poses a limitation for some registry 493 operators in that there is no way to verify that the trees are being 494 maintained in parallel without exhaustively walking the zones, which 495 may be large or nested to multiple levels. In the case, for example, 496 of a zone A.B.C.example.com, in which each of A,B,C are derived from 497 strings with a single character variant each, eight zones must be 498 maintained in parallel and possibly available for audit by the 499 authority over example.com, depending on its delegation policy. 501 3.1.2. Impact of special mechanisms 503 Once we begin to consider mechanisms for maintaining parallel zones 504 or "aliases", we need to look at how the "alias" or association 505 property is created and where the burden of maintaining it lies. In 506 the case of proposed mechanisms, we attempt to describe them below. 508 Existing mechanisms besides the simple, straightforward provisioning 509 of zones that are identical except for the ownernames of 510 corresponding records include wildcards, CNAME, and DNAME. See 511 below, but here we note that they require special processing by the 512 authority server in order to synthesize responses that are supposed 513 to be the equivalent of simply providing the parallel zones by one- 514 to-one enumeration. 516 3.2. Recursive Resolvers 518 Another area where it's necessary to review requirements and impacts 519 of changes to the DNS is in resolver expectations and behavior, given 520 that recursive resolvers do most of the work of getting the data out 521 of DNS that provisioning activities put into it. 523 In practice, much of the work of special processing falls to 524 resolvers. In particular, any scheme that can result in multiple 525 queries and some need to chain the answers or disambiguate multiple 526 answers is going to make more work for resolvers, and is going to 527 need to specify that work in careful detail. Any ambiguity or lack 528 of precision in specifying the use of "aliases" will propagate back 529 to applications, and quite possibly leave applications writers and 530 users worse off than they were without DNS mechanisms intended to 531 "help". 533 Ideally any new RRtypes defined to support "aliases" would be 534 provisioned on the authority server and require no special 535 processing, which would make them transparent to intermediate 536 resolvers. However, depending on how much such RRs and their 537 processing need to be visible to the application to be effective, 538 this may not be possible. 540 3.3. Applications 542 The most complex part of the analysis of costs and benefits of 543 defining new technology for support of "aliases" by DNS is in 544 determining what applications would do with such new mechanisms and 545 how it would help to have them. In particular, it is critically 546 important not to simply provide additional complexity, even in the 547 name of making provisioning on the server side easier, unless there's 548 some clear benefit to it for the ultimate client of the DNS as well-- 549 the user who is trying to "do something" on the Internet. 551 Such a clear benefit could come from the ability, alluded to above, 552 to provide a facility that was anchored in the DNS and so did not 553 have to be re-invented anew for each application or protocol that 554 wished to have user-transparent access to the ability to reduce 555 "aliases" to a canonical domain name without necessarily being aware, 556 a priori, that the name was part of a set that could be deemed "the 557 same". 559 An example used more than once in discussion is provided by SSL, as a 560 protocol that uses domain names without necessarily using the DNS 561 protocol per se. SSL certificates are tied to one domain name. It 562 would be helpful to applications to have a non-protocol-specific way 563 to identify securely cases where multiple domain names can be 564 canonicalized to the domain name used for an SSL certificate. 565 Currently HTTP has such an ability, but it's considered awkward to 566 use and does not help writers or users of other application 567 protocols. 569 An important characteristic of such a solution for applications, 570 however, is that the writer and user be able to tell when such a 571 mechanism was invoked in the DNS, to avoid interference among 572 multiple possible ways to find "aliases" and compare them. This in 573 turn implies a fair amount of complexity to be inflicted not only on 574 DNS protocol but also on API/library writers seeking to use such new 575 facilities. 577 Another characteristic of an "aliases" mechanism of interest to 578 application writers is the difficulty, and therefore the likely speed 579 and breadth of deployment, of such a DNS-based mechanism for 580 canonicalizing aliased names. DNS is notorious, as an aging 581 infrastructure protocol, for the long tail of deployment of 582 significant protocol features. Again, a feature can be designed to 583 be fairly easy to deploy, but without an incentive such as faster 584 application development or more secure applications, it stlil may not 585 see wide uptake even after it's present in current code bases. 587 4. Proposed Requirements 589 These observations and examples, along with general discussion to 590 date, lead to the following tentative set of actual requirements. 592 1. Any mechanism proposed in the DNS to support "aliases" or 593 multiple names as "the same" MUST be workable for DNSSEC- signed 594 zones. 595 2. Any mechanism proposed in the DNS to support "aliases" or 596 multiple names as "the same" MUST be "backwards compatible," in 597 that it MUST NOT change the established behavior of existing 598 RRtypes and query processing. 599 3. Any mechanism proposed SHOULD NOT require more overhead of 600 registries, authoritative servers, or clients than existing 601 mechanisms for approximating the desired behavior, such as 602 provisioning of multiple parallel trees or CNAME processing. If 603 a new solution is more work than existing mechanisms, imperfect 604 as they may be, it's not clear where the incentives would lie to 605 deploy it. This is particularly a concern for implementors and 606 application developers. 607 4. Any mechanism proposed MAY require new RRtypes and special 608 processing for them. 609 5. Any mechanism proposed MUST NOT only reduce costs of generating 610 and providing authoritative service for DNS zones. It would be 611 too easy to reduce costs on the authority server provider while 612 adding costs elsewhere, particularly in terms of complexity. 613 Given the central importance of DNS service to Internet 614 operations, any change undertaken to lower the cost to providers 615 may be useful, but should not simply shift costs to DNS users, 616 whether applications or end users. 618 5. Possible Solutions 620 Currently, there are several possible mechanisms to support identical 621 DNS resolution of "bundled" or "variant" names as "aliases" in the 622 DNS. Existing mechanisms in the DNS include CNAME and DNAME. In 623 addition, as described briefly above, registry operators have a great 624 many techniques for applying policy to what names can be registered, 625 and provisioning technology to how they are instantiated in the DNS, 626 in support of keeping "variant" names behaving similarly to each 627 other, or in preventing the use of such variants as might be 628 considered confusing or dangerous. 630 In addition, there are new proposals for DNS protocol to support 631 "aliases" in the DNS as part of the desired behavior of "variant" 632 names: Names direction[BNAME], and "Zone clone". 634 All of the solutions have their advantages and disadvantages. In 635 particular, there are a couple of limitations they all share. Every 636 mechanism existing or proposed to support "aliases" in the DNS 637 requires that one name be designated as the "canonical" name 638 ("preferred" in the terminology of the JET variant mechanism) and any 639 others bundled with it are to be considered "variants" or "aliases". 640 The only known way to enforce a symmetrical or equivalent association 641 is via careful registry provisioning within and across domains. In 642 addition, the different "alias" mechanisms differ in subtle ways that 643 have to be carefully reviewed against the desired behavior of the DNS 644 in support of different types of "variants". 646 5.1. Mapping or Redirection of Domain Names 648 5.1.1. Mapping itself 650 It was recognized as part of the original specification of the DNS 651 that a host can have many names; in fact this expectation predates 652 the DNS, referring to the earlier specification of host names. In 653 the simplest case for "aliases", Internet users need these multiple 654 names to be resolved to the same IP address by a DNS server. The 655 CNAME record [RFC1034], where "CNAME" is an abbreviation for 656 "Canonical Name", is a way to designate aliases of the "real" or 657 canonical name of a host. In some cases, CNAME can be used to 658 produce the necessary association a bundle of variant domain names. 659 But the CNAME only maps itself, not its descendants; in fact it is 660 defined to not have descendants, as it is the only name at a node in 661 the DNS tree and can't exist at the same name as delegation. In the 662 case of IDN variants, however, it is often desirable that the name 663 map both itself and its descendants. 665 5.1.2. Mapping its descendants 667 In order to maintain the address-to-name mappings in a context of 668 network renumbering, a DNAME record or Delegation Name record defined 669 by [RFC2672] was invented to create an alias for all its subdomains. 670 In contrast, the CNAME record creates an alias only of a single name 671 (and not of its subdomains). As with the CNAME record, the DNS 672 lookup will continue by retrying the lookup with the new name. If a 673 DNS resolver sends a query without EDNS[EDNS0], or with EDNS version 674 0, then a name server synthesizes a CNAME record to simulate the 675 semantics of the DNAME record. A DNAME record is very much like the 676 CNAME record, but while the CNAME record only applies for one name, 677 with a DNAME record one can create aliases for all the records for 678 its subdomain. 680 5.1.3. Mapping itself and its descendants 682 Bundling of "variant" strings or names as domain names, possibly 683 along with other use cases not yet identified, require the ability to 684 map a whole tree of the domain space to another domain. The current 685 DNS protocols do not support this function. A new DNS resource 686 record [BNAME] has been proposed to deal with this problem. 688 The advantage of BNAME is that it would enable a class of "aliasing" 689 behavior that some operators find desirable, particularly in 690 preference to some of the provisioning overhead they describe having 691 to deploy to support potentially large numbers of "bundles" of 692 variants at multiple levels of the DNS tree. The disadvantage is 693 that it may not provide the behavior people really want while 694 requiring the time and resources to code and deploy any new DNS 695 facility. 697 Alternatively, a proposal has been made that would leave CNAME as 698 already specified, but eliminating the constraint that a CNAME must 699 be alone at a node in the DNS tree. This would avoid any coding and 700 deployment overhead associated with new RRtypes, while obtaining the 701 desired behavior. Concerns expressed about it, however, include the 702 possible (but not yet specified) effort required for backwards 703 compatibility to avoid harm to implementations that expect, and use, 704 the old behavior. 706 5.2. Zone Clone 708 The proposal of "zone clone" or "dns shadow", is an alternative 709 solution for a higher level of support than the DNS currently 710 provides for "alias" behavior across zones. In this scheme, a new 711 RRtype, SHADOW, is specified; it can exist at a zone apex and can be 712 used to define "clones" or "shadows" of the zone content so that 713 records in the zone are reachable via lookups from multiple 714 delegations. This mechanism varies fundamentally from CNAME/DNAME/ 715 BNAME in that it creates a local copy on each cooperating 716 authoritative server that has the original zone, reachable by the 717 names specified in the SHADOW RR. Its scope, then, is the zone as 718 maintained by an authoritative server rather than a single RRset 719 (even one corresponding to a delegation). 721 This scheme has the advantage that it allows a SHADOW zone to be used 722 in all the same contexts as the canonical or underlying zone, 723 including contexts where a CNAME or DNAME (or, presumably, a BNAME) 724 cannot appear, such as in the RDATA of certain RRtypes. Of the 725 proposed DNS protocol mechanisms, it probably comes closest to the 726 behavior some have requested as "equivalence," where none of the 727 bundled or SHADOW names is canonical or preferred over the others. 729 It does implicate an unknown level of effort to implement and 730 support. 732 6. IANA Considerations 734 There are no obvious IANA considerations in this memo; we reiterate 735 that the determination of which names are to be considered "the same" 736 is explicitly out of scope. 738 7. Security Considerations 740 [STW: Looking for examples for this section.] 742 Unsolved issues that will have to be considered in the definition of 743 what "the same" means for the DNS include the implications for 744 DNSSEC, and whether "identical" resolution includes DNSSEC validation 745 in the expected "identical" behavior. 747 Another area of possible peril includes SSL certificates, "Host" 748 headers as seen by web servers, and other security-relevant data 749 often associated with domain names. It will have to be considered 750 whether, and how, the "sameness" property maps into the expected 751 behavior of security-related protocols that use domain names, 752 particularly given that it's unlikely that all operators will ever 753 use the same set of constructs (whether in the DNS or elsewhere) to 754 signal whether different "names" are "the same" for purposes of the 755 function of a particular application or protocol. 757 In addition, there is a large cluster of security risks at the user 758 and application levels that motivate significant portions of the 759 interest in what it means to treat a set of names as "aliases" of 760 each other. One set of issues is around the expectation that two 761 strings are seen as "different" by the user in some obvious way (such 762 as visually) but need to be treated as "the same". The potential for 763 user confusion and subversion is not hard to imagine in cases where 764 two visually distinct strings are nonetheless likely to be expected 765 by the user to behave "the same" in some functional way. This is the 766 case we have attempted to address here. 768 There is a separate but complementary set of issues that arise around 769 cases where strings that look "the same" should nonetheless be 770 treated as different-- the so-called "confusing visual similarity" 771 problem. The easy example is substituting the Unicode codepoint for 772 a character in one script, or a string of them, for the Unicode 773 codepoints for similar-looking characters in an altogether different 774 script. This has a different set of potential risks to users, and 775 has not been discussed here. It's often closely related to the 776 "alias" issue we have attempted to deal with, however, which poses 777 risks of its own to analysis of the either subject. 779 8. Acknowledgements 781 Most of the ideas here and much of the text is taken from discussions 782 on the DNSEXT and DNSOP WG mailing lists. Particular help is 783 acknowledged from the authors of the proposed solutions drafts, and 784 from the many contributors to the IDNAbis work and its underpinnings. 785 Special thanks at the intersection of DNS and IDNAbis is owed to 786 Patrik Faltstrom, Cary Karp, John Klensin, Vaggelis Segredakis, and 787 Andrew Sullivan for their patient explanations. 789 9. Change History 791 [[anchor28: RFC Editor: Please remove this section.]] 793 9.1. draft-yao-dnsext-identical-resolution: Version 00 795 o Domain Name Identical Resolution Problem Statement (initial 796 attempt) 798 9.2. draft-yao-dnsext-identical-resolution: Version 01 800 o Expanded introduction 801 o Added Greek example 802 o Added some detail to descriptions of proposed solutions 804 10. References 806 10.1. Normative References 808 [ASCII] American National Standards Institute (formerly United 809 States of America Standards Institute), "USA Code for 810 Information Interchange", ANSI X3.4-1968, 1968. 812 [EDNS0] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", 813 RFC 2671, August 1999. 815 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 816 STD 13, RFC 1034, November 1987. 818 [RFC1035] Mockapetris, P., "Domain names - implementation and 819 specification", STD 13, RFC 1035, November 1987. 821 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 822 Requirement Levels", BCP 14, RFC 2119, March 1997. 824 [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, 825 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 826 RFC 2136, April 1997. 828 [RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection", 829 RFC 2672, August 1999. 831 [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, 832 "Internationalizing Domain Names in Applications (IDNA)", 833 RFC 3490, March 2003. 835 [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record 836 (RR) Types", RFC 3597, September 2003. 838 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 839 10646", RFC 3629, November 2003. 841 [RFC3743] Konishi, K., Huang, K., Qian, H., and Y. Ko, "Joint 842 Engineering Team (JET) Guidelines for Internationalized 843 Domain Names (IDN) Registration and Administration for 844 Chinese, Japanese, and Korean", RFC 3743, April 2004. 846 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 847 Rose, "DNS Security Introduction and Requirements", 848 RFC 4033, March 2005. 850 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 851 Rose, "Resource Records for the DNS Security Extensions", 852 RFC 4034, March 2005. 854 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 855 Rose, "Protocol Modifications for the DNS Security 856 Extensions", RFC 4035, March 2005. 858 [RFC4290] Klensin, J., "Suggested Practices for Registration of 859 Internationalized Domain Names (IDN)", RFC 4290, 860 December 2005. 862 [RFC4690] Klensin, J., Faltstrom, P., Karp, C., and IAB, "Review and 863 Recommendations for Internationalized Domain Names 864 (IDNs)", RFC 4690, September 2006. 866 10.2. Informative References 868 [BNAME] Yao, J., Lee, X., and P. Vixie, "Bundle DNS Name 869 Redirection", draft-yao-dnsext-bname-01.txt (work in 870 progress), 12 2009. 872 [CNAME-DNAME] 873 Sury, O., "CNAME+DNAME Name Redirection", 874 draft-sury-dnsext-cname-dname-00.txt (work in progress), 875 4 2010. 877 [IDN-TLD-Variants] 878 Yao, J. and X. Lee, "IDN TLD Variants Implementation 879 Guideline", draft-yao-dnsop-idntld-implementation-01.txt 880 (work in progress), 11 2009. 882 [RFC2672bis] 883 Rose, S. and W. Wijngaards, "Update to DNAME Redirection 884 in the DNS", Internet-Draft ietf-dnsext-rfc2672bis-dname- 885 17.txt, 6 2009. 887 [SHADOW] Vixie, P., "Use of DNS to Carry Configuration Metadata 888 Concerning Automatic Replication of Zones", 889 draft-vixie-dnsext-dnsshadow-00.txt (work in progress), 890 2 2010. 892 Authors' Addresses 894 Suzanne Woolf 895 Internet Systems Consortium, Inc. 896 950 Charter St. 897 Redwood City, CA 94063 899 Phone: +1 650 423 1333 900 Email: woolf@isc.org 902 Xiaodong LEE 903 CNNIC 904 No.4 South 4th Street, Zhongguancun 905 Beijing 907 Phone: +86 10 58813020 908 Email: lee@cnnic.cn