diff options
Diffstat (limited to 'contrib/bind9/doc/rfc/rfc3467.txt')
| -rw-r--r-- | contrib/bind9/doc/rfc/rfc3467.txt | 1739 |
1 files changed, 0 insertions, 1739 deletions
diff --git a/contrib/bind9/doc/rfc/rfc3467.txt b/contrib/bind9/doc/rfc/rfc3467.txt deleted file mode 100644 index 37ac7ec1d930..000000000000 --- a/contrib/bind9/doc/rfc/rfc3467.txt +++ /dev/null @@ -1,1739 +0,0 @@ - - - - - - -Network Working Group J. Klensin -Request for Comments: 3467 February 2003 -Category: Informational - - - Role of the Domain Name System (DNS) - -Status of this Memo - - This memo provides information for the Internet community. It does - not specify an Internet standard of any kind. Distribution of this - memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (2003). All Rights Reserved. - -Abstract - - This document reviews the original function and purpose of the domain - name system (DNS). It contrasts that history with some of the - purposes for which the DNS has recently been applied and some of the - newer demands being placed upon it or suggested for it. A framework - for an alternative to placing these additional stresses on the DNS is - then outlined. This document and that framework are not a proposed - solution, only a strong suggestion that the time has come to begin - thinking more broadly about the problems we are encountering and - possible approaches to solving them. - -Table of Contents - - 1. Introduction and History ..................................... 2 - 1.1 Context for DNS Development ............................... 3 - 1.2 Review of the DNS and Its Role as Designed ................ 4 - 1.3 The Web and User-visible Domain Names ..................... 6 - 1.4 Internet Applications Protocols and Their Evolution ....... 7 - 2. Signs of DNS Overloading ..................................... 8 - 3. Searching, Directories, and the DNS .......................... 12 - 3.1 Overview ................................................. 12 - 3.2 Some Details and Comments ................................. 14 - 4. Internationalization ......................................... 15 - 4.1 ASCII Isn't Just Because of English ....................... 16 - 4.2 The "ASCII Encoding" Approaches ........................... 17 - 4.3 "Stringprep" and Its Complexities ......................... 17 - 4.4 The Unicode Stability Problem ............................. 19 - 4.5 Audiences, End Users, and the User Interface Problem ...... 20 - 4.6 Business Cards and Other Natural Uses of Natural Languages. 22 - 4.7 ASCII Encodings and the Roman Keyboard Assumption ......... 22 - - - -Klensin Informational [Page 1] - -RFC 3467 Role of the Domain Name System (DNS) February 2003 - - - 4.8 Intra-DNS Approaches for "Multilingual Names" ............. 23 - 5. Search-based Systems: The Key Controversies .................. 23 - 6. Security Considerations ...................................... 24 - 7. References ................................................... 25 - 7.1 Normative References ...................................... 25 - 7.2 Explanatory and Informative References .................... 25 - 8. Acknowledgements ............................................. 30 - 9. Author's Address ............................................. 30 - 10. Full Copyright Statement ..................................... 31 - -1. Introduction and History - - The DNS was designed as a replacement for the older "host table" - system. Both were intended to provide names for network resources at - a more abstract level than network (IP) addresses (see, e.g., - [RFC625], [RFC811], [RFC819], [RFC830], [RFC882]). In recent years, - the DNS has become a database of convenience for the Internet, with - many proposals to add new features. Only some of these proposals - have been successful. Often the main (or only) motivation for using - the DNS is because it exists and is widely deployed, not because its - existing structure, facilities, and content are appropriate for the - particular application of data involved. This document reviews the - history of the DNS, including examination of some of those newer - applications. It then argues that the overloading process is often - inappropriate. Instead, it suggests that the DNS should be - supplemented by systems better matched to the intended applications - and outlines a framework and rationale for one such system. - - Several of the comments that follow are somewhat revisionist. Good - design and engineering often requires a level of intuition by the - designers about things that will be necessary in the future; the - reasons for some of these design decisions are not made explicit at - the time because no one is able to articulate them. The discussion - below reconstructs some of the decisions about the Internet's primary - namespace (the "Class=IN" DNS) in the light of subsequent development - and experience. In addition, the historical reasons for particular - decisions about the Internet were often severely underdocumented - contemporaneously and, not surprisingly, different participants have - different recollections about what happened and what was considered - important. Consequently, the quasi-historical story below is just - one story. There may be (indeed, almost certainly are) other stories - about how the DNS evolved to its present state, but those variants do - not invalidate the inferences and conclusions. - - This document presumes a general understanding of the terminology of - RFC 1034 [RFC1034] or of any good DNS tutorial (see, e.g., [Albitz]). - - - - - -Klensin Informational [Page 2] - -RFC 3467 Role of the Domain Name System (DNS) February 2003 - - -1.1 Context for DNS Development - - During the entire post-startup-period life of the ARPANET and nearly - the first decade or so of operation of the Internet, the list of host - names and their mapping to and from addresses was maintained in a - frequently-updated "host table" [RFC625], [RFC811], [RFC952]. The - names themselves were restricted to a subset of ASCII [ASCII] chosen - to avoid ambiguities in printed form, to permit interoperation with - systems using other character codings (notably EBCDIC), and to avoid - the "national use" code positions of ISO 646 [IS646]. These - restrictions later became collectively known as the "LDH" rules for - "letter-digit-hyphen", the permitted characters. The table was just - a list with a common format that was eventually agreed upon; sites - were expected to frequently obtain copies of, and install, new - versions. The host tables themselves were introduced to: - - o Eliminate the requirement for people to remember host numbers - (addresses). Despite apparent experience to the contrary in the - conventional telephone system, numeric numbering systems, - including the numeric host number strategy, did not (and do not) - work well for more than a (large) handful of hosts. - - o Provide stability when addresses changed. Since addresses -- to - some degree in the ARPANET and more importantly in the - contemporary Internet -- are a function of network topology and - routing, they often had to be changed when connectivity or - topology changed. The names could be kept stable even as - addresses changed. - - o Provide the capability to have multiple addresses associated with - a given host to reflect different types of connectivity and - topology. Use of names, rather than explicit addresses, avoided - the requirement that would otherwise exist for users and other - hosts to track these multiple host numbers and addresses and the - topological considerations for selecting one over others. - - After several years of using the host table approach, the community - concluded that model did not scale adequately and that it would not - adequately support new service variations. A number of discussions - and meetings were held which drew several ideas and incomplete - proposals together. The DNS was the result of that effort. It - continued to evolve during the design and initial implementation - period, with a number of documents recording the changes (see - [RFC819], [RFC830], and [RFC1034]). - - - - - - - -Klensin Informational [Page 3] - -RFC 3467 Role of the Domain Name System (DNS) February 2003 - - - The goals for the DNS included: - - o Preservation of the capabilities of the host table arrangements - (especially unique, unambiguous, host names), - - o Provision for addition of additional services (e.g., the special - record types for electronic mail routing which quickly followed - introduction of the DNS), and - - o Creation of a robust, hierarchical, distributed, name lookup - system to accomplish the other goals. - - The DNS design also permitted distribution of name administration, - rather than requiring that each host be entered into a single, - central, table by a central administration. - -1.2 Review of the DNS and Its Role as Designed - - The DNS was designed to identify network resources. Although there - was speculation about including, e.g., personal names and email - addresses, it was not designed primarily to identify people, brands, - etc. At the same time, the system was designed with the flexibility - to accommodate new data types and structures, both through the - addition of new record types to the initial "INternet" class, and, - potentially, through the introduction of new classes. Since the - appropriate identifiers and content of those future extensions could - not be anticipated, the design provided that these fields could - contain any (binary) information, not just the restricted text forms - of the host table. - - However, the DNS, as it is actually used, is intimately tied to the - applications and application protocols that utilize it, often at a - fairly low level. - - In particular, despite the ability of the protocols and data - structures themselves to accommodate any binary representation, DNS - names as used were historically not even unrestricted ASCII, but a - very restricted subset of it, a subset that derives from the original - host table naming rules. Selection of that subset was driven in part - by human factors considerations, including a desire to eliminate - possible ambiguities in an international context. Hence character - codes that had international variations in interpretation were - excluded, the underscore character and case distinctions were - eliminated as being confusing (in the underscore's case, with the - hyphen character) when written or read by people, and so on. These - considerations appear to be very similar to those that resulted in - similarly restricted character sets being used as protocol elements - in many ITU and ISO protocols (cf. [X29]). - - - -Klensin Informational [Page 4] - -RFC 3467 Role of the Domain Name System (DNS) February 2003 - - - Another assumption was that there would be a high ratio of physical - hosts to second level domains and, more generally, that the system - would be deeply hierarchical, with most systems (and names) at the - third level or below and a very large percentage of the total names - representing physical hosts. There are domains that follow this - model: many university and corporate domains use fairly deep - hierarchies, as do a few country-oriented top level domains - ("ccTLDs"). Historically, the "US." domain has been an excellent - example of the deeply hierarchical approach. However, by 1998, - comparison of several efforts to survey the DNS showed a count of SOA - records that approached (and may have passed) the number of distinct - hosts. Looked at differently, we appear to be moving toward a - situation in which the number of delegated domains on the Internet is - approaching or exceeding the number of hosts, or at least the number - of hosts able to provide services to others on the network. This - presumably results from synonyms or aliases that map a great many - names onto a smaller number of hosts. While experience up to this - time has shown that the DNS is robust enough -- given contemporary - machines as servers and current bandwidth norms -- to be able to - continue to operate reasonably well when those historical assumptions - are not met (e.g., with a flat, structure under ".COM" containing - well over ten million delegated subdomains [COMSIZE]), it is still - useful to remember that the system could have been designed to work - optimally with a flat structure (and very large zones) rather than a - deeply hierarchical one, and was not. - - Similarly, despite some early speculation about entering people's - names and email addresses into the DNS directly (e.g., see - [RFC1034]), electronic mail addresses in the Internet have preserved - the original, pre-DNS, "user (or mailbox) at location" conceptual - format rather than a flatter or strictly dot-separated one. - Location, in that instance, is a reference to a host. The sole - exception, at least in the "IN" class, has been one field of the SOA - record. - - Both the DNS architecture itself and the two-level (host name and - mailbox name) provisions for email and similar functions (e.g., see - the finger protocol [FINGER]), also anticipated a relatively high - ratio of users to actual hosts. Despite the observation in RFC 1034 - that the DNS was expected to grow to be proportional to the number of - users (section 2.3), it has never been clear that the DNS was - seriously designed for, or could, scale to the order of magnitude of - number of users (or, more recently, products or document objects), - rather than that of physical hosts. - - Just as was the case for the host table before it, the DNS provided - critical uniqueness for names, and universal accessibility to them, - as part of overall "single internet" and "end to end" models (cf. - - - -Klensin Informational [Page 5] - -RFC 3467 Role of the Domain Name System (DNS) February 2003 - - - [RFC2826]). However, there are many signs that, as new uses evolved - and original assumptions were abused (if not violated outright), the - system was being stretched to, or beyond, its practical limits. - - The original design effort that led to the DNS included examination - of the directory technologies available at the time. The design - group concluded that the DNS design, with its simplifying assumptions - and restricted capabilities, would be feasible to deploy and make - adequately robust, which the more comprehensive directory approaches - were not. At the same time, some of the participants feared that the - limitations might cause future problems; this document essentially - takes the position that they were probably correct. On the other - hand, directory technology and implementations have evolved - significantly in the ensuing years: it may be time to revisit the - assumptions, either in the context of the two- (or more) level - mechanism contemplated by the rest of this document or, even more - radically, as a path toward a DNS replacement. - -1.3 The Web and User-visible Domain Names - - From the standpoint of the integrity of the domain name system -- and - scaling of the Internet, including optimal accessibility to content - -- the web design decision to use "A record" domain names directly in - URLs, rather than some system of indirection, has proven to be a - serious mistake in several respects. Convenience of typing, and the - desire to make domain names out of easily-remembered product names, - has led to a flattening of the DNS, with many people now perceiving - that second-level names under COM (or in some countries, second- or - third-level names under the relevant ccTLD) are all that is - meaningful. This perception has been reinforced by some domain name - registrars [REGISTRAR] who have been anxious to "sell" additional - names. And, of course, the perception that one needed a second-level - (or even top-level) domain per product, rather than having names - associated with a (usually organizational) collection of network - resources, has led to a rapid acceleration in the number of names - being registered. That acceleration has, in turn, clearly benefited - registrars charging on a per-name basis, "cybersquatters", and others - in the business of "selling" names, but it has not obviously - benefited the Internet as a whole. - - This emphasis on second-level domain names has also created a problem - for the trademark community. Since the Internet is international, - and names are being populated in a flat and unqualified space, - similarly-named entities are in conflict even if there would - ordinarily be no chance of confusing them in the marketplace. The - problem appears to be unsolvable except by a choice between draconian - measures. These might include significant changes to the legislation - and conventions that govern disputes over "names" and "marks". Or - - - -Klensin Informational [Page 6] - -RFC 3467 Role of the Domain Name System (DNS) February 2003 - - - they might result in a situation in which the "rights" to a name are - typically not settled using the subtle and traditional product (or - industry) type and geopolitical scope rules of the trademark system. - Instead they have depended largely on political or economic power, - e.g., the organization with the greatest resources to invest in - defending (or attacking) names will ultimately win out. The latter - raises not only important issues of equity, but also the risk of - backlash as the numerous small players are forced to relinquish names - they find attractive and to adopt less-desirable naming conventions. - - Independent of these sociopolitical problems, content distribution - issues have made it clear that it should be possible for an - organization to have copies of data it wishes to make available - distributed around the network, with a user who asks for the - information by name getting the topologically-closest copy. This is - not possible with simple, as-designed, use of the DNS: DNS names - identify target resources or, in the case of email "MX" records, a - preferentially-ordered list of resources "closest" to a target (not - to the source/user). Several technologies (and, in some cases, - corresponding business models) have arisen to work around these - problems, including intercepting and altering DNS requests so as to - point to other locations. - - Additional implications are still being discovered and evaluated. - - Approaches that involve interception of DNS queries and rewriting of - DNS names (or otherwise altering the resolution process based on the - topological location of the user) seem, however, to risk disrupting - end-to-end applications in the general case and raise many of the - issues discussed by the IAB in [IAB-OPES]. These problems occur even - if the rewriting machinery is accompanied by additional workarounds - for particular applications. For example, security associations and - applications that need to identify "the same host" often run into - problems if DNS names or other references are changed in the network - without participation of the applications that are trying to invoke - the associated services. - -1.4 Internet Applications Protocols and Their Evolution - - At the applications level, few of the protocols in active, - widespread, use on the Internet reflect either contemporary knowledge - in computer science or human factors or experience accumulated - through deployment and use. Instead, protocols tend to be deployed - at a just-past-prototype level, typically including the types of - expedient compromises typical with prototypes. If they prove useful, - the nature of the network permits very rapid dissemination (i.e., - they fill a vacuum, even if a vacuum that no one previously knew - existed). But, once the vacuum is filled, the installed base - - - -Klensin Informational [Page 7] - -RFC 3467 Role of the Domain Name System (DNS) February 2003 - - - provides its own inertia: unless the design is so seriously faulty as - to prevent effective use (or there is a widely-perceived sense of - impending disaster unless the protocol is replaced), future - developments must maintain backward compatibility and workarounds for - problematic characteristics rather than benefiting from redesign in - the light of experience. Applications that are "almost good enough" - prevent development and deployment of high-quality replacements. - - The DNS is both an illustration of, and an exception to, parts of - this pessimistic interpretation. It was a second-generation - development, with the host table system being seen as at the end of - its useful life. There was a serious attempt made to reflect the - computing state of the art at the time. However, deployment was much - slower than expected (and very painful for many sites) and some fixed - (although relaxed several times) deadlines from a central network - administration were necessary for deployment to occur at all. - Replacing it now, in order to add functionality, while it continues - to perform its core functions at least reasonably well, would - presumably be extremely difficult. - - There are many, perhaps obvious, examples of this. Despite many - known deficiencies and weaknesses of definition, the "finger" and - "whois" [WHOIS] protocols have not been replaced (despite many - efforts to update or replace the latter [WHOIS-UPDATE]). The Telnet - protocol and its many options drove out the SUPDUP [RFC734] one, - which was arguably much better designed for a diverse collection of - network hosts. A number of efforts to replace the email or file - transfer protocols with models which their advocates considered much - better have failed. And, more recently and below the applications - level, there is some reason to believe that this resistance to change - has been one of the factors impeding IPv6 deployment. - -2. Signs of DNS Overloading - - Parts of the historical discussion above identify areas in which the - DNS has become overloaded (semantically if not in the mechanical - ability to resolve names). Despite this overloading, it appears that - DNS performance and reliability are still within an acceptable range: - there is little evidence of serious performance degradation. Recent - proposals and mechanisms to better respond to overloading and scaling - issues have all focused on patching or working around limitations - that develop when the DNS is utilized for out-of-design functions, - rather than on dramatic rethinking of either DNS design or those - uses. The number of these issues that have arisen at much the same - time may argue for just that type of rethinking, and not just for - adding complexity and attempting to incrementally alter the design - (see, for example, the discussion of simplicity in section 2 of - [RFC3439]). - - - -Klensin Informational [Page 8] - -RFC 3467 Role of the Domain Name System (DNS) February 2003 - - - For example: - - o While technical approaches such as larger and higher-powered - servers and more bandwidth, and legal/political mechanisms such as - dispute resolution policies, have arguably kept the problems from - becoming critical, the DNS has not proven adequately responsive to - business and individual needs to describe or identify things (such - as product names and names of individuals) other than strict - network resources. - - o While stacks have been modified to better handle multiple - addresses on a physical interface and some protocols have been - extended to include DNS names for determining context, the DNS - does not deal especially well with many names associated with a - given host (e.g., web hosting facilities with multiple domains on - a server). - - o Efforts to add names deriving from languages or character sets - based on other than simple ASCII and English-like names (see - below), or even to utilize complex company or product names - without the use of hierarchy, have created apparent requirements - for names (labels) that are over 63 octets long. This requirement - will undoubtedly increase over time; while there are workarounds - to accommodate longer names, they impose their own restrictions - and cause their own problems. - - o Increasing commercialization of the Internet, and visibility of - domain names that are assumed to match names of companies or - products, has turned the DNS and DNS names into a trademark - battleground. The traditional trademark system in (at least) most - countries makes careful distinctions about fields of - applicability. When the space is flattened, without - differentiation by either geography or industry sector, not only - are there likely conflicts between "Joe's Pizza" (of Boston) and - "Joe's Pizza" (of San Francisco) but between both and "Joe's Auto - Repair" (of Los Angeles). All three would like to control - "Joes.com" (and would prefer, if it were permitted by DNS naming - rules, to also spell it as "Joe's.com" and have both resolve the - same way) and may claim trademark rights to do so, even though - conflict or confusion would not occur with traditional trademark - principles. - - o Many organizations wish to have different web sites under the same - URL and domain name. Sometimes this is to create local variations - -- the Widget Company might want to present different material to - a UK user relative to a US one -- and sometimes it is to provide - higher performance by supplying information from the server - topologically closest to the user. If the name resolution - - - -Klensin Informational [Page 9] - -RFC 3467 Role of the Domain Name System (DNS) February 2003 - - - mechanism is expected to provide this functionality, there are - three possible models (which might be combined): - - - supply information about multiple sites (or locations or - references). Those sites would, in turn, provide information - associated with the name and sufficient site-specific - attributes to permit the application to make a sensible choice - of destination, or - - - accept client-site attributes and utilize them in the search - process, or - - - return different answers based on the location or identity of - the requestor. - - While there are some tricks that can provide partial simulations of - these types of function, DNS responses cannot be reliably conditioned - in this way. - - These, and similar, issues of performance or content choices can, of - course, be thought of as not involving the DNS at all. For example, - the commonly-cited alternate approach of coupling these issues to - HTTP content negotiation (cf. [RFC2295]), requires that an HTTP - connection first be opened to some "common" or "primary" host so that - preferences can be negotiated and then the client redirected or sent - alternate data. At least from the standpoint of improving - performance by accessing a "closer" location, both initially and - thereafter, this approach sacrifices the desired result before the - client initiates any action. It could even be argued that some of - the characteristics of common content negotiation approaches are - workarounds for the non-optimal use of the DNS in web URLs. - - o Many existing and proposed systems for "finding things on the - Internet" require a true search capability in which near matches - can be reported to the user (or to some user agent with an - appropriate rule-set) and to which queries may be ambiguous or - fuzzy. The DNS, by contrast, can accommodate only one set of - (quite rigid) matching rules. Proposals to permit different rules - in different localities (e.g., matching rules that are TLD- or - zone-specific) help to identify the problem. But they cannot be - applied directly to the DNS without either abandoning the desired - level of flexibility or isolating different parts of the Internet - from each other (or both). Fuzzy or ambiguous searches are - desirable for resolution of names that might have spelling - variations and for names that can be resolved into different sets - of glyphs depending on context. Especially when - internationalization is considered, variant name problems go - beyond simple differences in representation of a character or - - - -Klensin Informational [Page 10] - -RFC 3467 Role of the Domain Name System (DNS) February 2003 - - - ordering of a string. Instead, avoiding user astonishment and - confusion requires consideration of relationships such as - languages that can be written with different alphabets, Kanji- - Hiragana relationships, Simplified and Traditional Chinese, etc. - See [Seng] for a discussion and suggestions for addressing a - subset of these issues in the context of characters based on - Chinese ones. But that document essentially illustrates the - difficulty of providing the type of flexible matching that would - be anticipated by users; instead, it tries to protect against the - worst types of confusion (and opportunities for fraud). - - o The historical DNS, and applications that make assumptions about - how it works, impose significant risk (or forces technical kludges - and consequent odd restrictions), when one considers adding - mechanisms for use with various multi-character-set and - multilingual "internationalization" systems. See the IAB's - discussion of some of these issues [RFC2825] for more information. - - o In order to provide proper functionality to the Internet, the DNS - must have a single unique root (the IAB provides more discussion - of this issue [RFC2826]). There are many desires for local - treatment of names or character sets that cannot be accommodated - without either multiple roots (e.g., a separate root for - multilingual names, proposed at various times by MINC [MINC] and - others), or mechanisms that would have similar effects in terms of - Internet fragmentation and isolation. - - o For some purposes, it is desirable to be able to search not only - an index entry (labels or fully-qualified names in the DNS case), - but their values or targets (DNS data). One might, for example, - want to locate all of the host (and virtual host) names which - cause mail to be directed to a given server via MX records. The - DNS does not support this capability (see the discussion in - [IQUERY]) and it can be simulated only by extracting all of the - relevant records (perhaps by zone transfer if the source permits - doing so, but that permission is becoming less frequently - available) and then searching a file built from those records. - - o Finally, as additional types of personal or identifying - information are added to the DNS, issues arise with protection of - that information. There are increasing calls to make different - information available based on the credentials and authorization - of the source of the inquiry. As with information keyed to site - locations or proximity (as discussed above), the DNS protocols - make providing these differentiated services quite difficult if - not impossible. - - - - - -Klensin Informational [Page 11] - -RFC 3467 Role of the Domain Name System (DNS) February 2003 - - - In each of these cases, it is, or might be, possible to devise ways - to trick the DNS system into supporting mechanisms that were not - designed into it. Several ingenious solutions have been proposed in - many of these areas already, and some have been deployed into the - marketplace with some success. But the price of each of these - changes is added complexity and, with it, added risk of unexpected - and destabilizing problems. - - Several of the above problems are addressed well by a good directory - system (supported by the LDAP protocol or some protocol more - precisely suited to these specific applications) or searching - environment (such as common web search engines) although not by the - DNS. Given the difficulty of deploying new applications discussed - above, an important question is whether the tricks and kludges are - bad enough, or will become bad enough as usage grows, that new - solutions are needed and can be deployed. - -3. Searching, Directories, and the DNS - -3.1 Overview - - The constraints of the DNS and the discussion above suggest the - introduction of an intermediate protocol mechanism, referred to below - as a "search layer" or "searchable system". The terms "directory" - and "directory system" are used interchangeably with "searchable - system" in this document, although the latter is far more precise. - Search layer proposals would use a two (or more) stage lookup, not - unlike several of the proposals for internationalized names in the - DNS (see section 4), but all operations but the final one would - involve searching other systems, rather than looking up identifiers - in the DNS itself. As explained below, this would permit relaxation - of several constraints, leading to a more capable and comprehensive - overall system. - - Ultimately, many of the issues with domain names arise as the result - of efforts to use the DNS as a directory. While, at the time this - document was written, sufficient pressure or demand had not occurred - to justify a change, it was already quite clear that, as a directory - system, the DNS is a good deal less than ideal. This document - suggests that there actually is a requirement for a directory system, - and that the right solution to a searchable system requirement is a - searchable system, not a series of DNS patches, kludges, or - workarounds. - - - - - - - - -Klensin Informational [Page 12] - -RFC 3467 Role of the Domain Name System (DNS) February 2003 - - - The following points illustrate particular aspects of this - conclusion. - - o A directory system would not require imposition of particular - length limits on names. - - o A directory system could permit explicit association of - attributes, e.g., language and country, with a name, without - having to utilize trick encodings to incorporate that information - in DNS labels (or creating artificial hierarchy for doing so). - - o There is considerable experience (albeit not much of it very - successful) in doing fuzzy and "sonex" (similar-sounding) matching - in directory systems. Moreover, it is plausible to think about - different matching rules for different areas and sets of names so - that these can be adapted to local cultural requirements. - Specifically, it might be possible to have a single form of a name - in a directory, but to have great flexibility about what queries - matched that name (and even have different variations in different - areas). Of course, the more flexibility that a system provides, - the greater the possibility of real or imagined trademark - conflicts. But the opportunity would exist to design a directory - structure that dealt with those issues in an intelligent way, - while DNS constraints almost certainly make a general and - equitable DNS-only solution impossible. - - o If a directory system is used to translate to DNS names, and then - DNS names are looked up in the normal fashion, it may be possible - to relax several of the constraints that have been traditional - (and perhaps necessary) with the DNS. For example, reverse- - mapping of addresses to directory names may not be a requirement - even if mapping of addresses to DNS names continues to be, since - the DNS name(s) would (continue to) uniquely identify the host. - - o Solutions to multilingual transcription problems that are common - in "normal life" (e.g., two-sided business cards to be sure that - recipients trying to contact a person can access romanized - spellings and numbers if the original language is not - comprehensible to them) can be easily handled in a directory - system by inserting both sets of entries. - - o A directory system could be designed that would return, not a - single name, but a set of names paired with network-locational - information or other context-establishing attributes. This type - of information might be of considerable use in resolving the - "nearest (or best) server for a particular named resource" - - - - - -Klensin Informational [Page 13] - -RFC 3467 Role of the Domain Name System (DNS) February 2003 - - - problems that are a significant concern for organizations hosting - web and other sites that are accessed from a wide range of - locations and subnets. - - o Names bound to countries and languages might help to manage - trademark realities, while, as discussed in section 1.3 above, use - of the DNS in trademark-significant contexts tends to require - worldwide "flattening" of the trademark system. - - Many of these issues are a consequence of another property of the - DNS: names must be unique across the Internet. The need to have a - system of unique identifiers is fairly obvious (see [RFC2826]). - However, if that requirement were to be eliminated in a search or - directory system that was visible to users instead of the DNS, many - difficult problems -- of both an engineering and a policy nature -- - would be likely to vanish. - -3.2 Some Details and Comments - - Almost any internationalization proposal for names that are in, or - map into, the DNS will require changing DNS resolver API calls - ("gethostbyname" or equivalent), or adding some pre-resolution - preparation mechanism, in almost all Internet applications -- whether - to cause the API to take a different character set (no matter how it - is then mapped into the bits used in the DNS or another system), to - accept or return more arguments with qualifying or identifying - information, or otherwise. Once applications must be opened to make - such changes, it is a relatively small matter to switch from calling - into the DNS to calling a directory service and then the DNS (in many - situations, both actions could be accomplished in a single API call). - - A directory approach can be consistent both with "flat" models and - multi-attribute ones. The DNS requires strict hierarchies, limiting - its ability to differentiate among names by their properties. By - contrast, modern directories can utilize independently-searched - attributes and other structured schema to provide flexibilities not - present in a strictly hierarchical system. - - There is a strong historical argument for a single directory - structure (implying a need for mechanisms for registration, - delegation, etc.). But a single structure is not a strict - requirement, especially if in-depth case analysis and design work - leads to the conclusion that reverse-mapping to directory names is - not a requirement (see section 5). If a single structure is not - needed, then, unlike the DNS, there would be no requirement for a - global organization to authorize or delegate operation of portions of - the structure. - - - - -Klensin Informational [Page 14] - -RFC 3467 Role of the Domain Name System (DNS) February 2003 - - - The "no single structure" concept could be taken further by moving - away from simple "names" in favor of, e.g., multiattribute, - multihierarchical, faceted systems in which most of the facets use - restricted vocabularies. (These terms are fairly standard in the - information retrieval and classification system literature, see, - e.g., [IS5127].) Such systems could be designed to avoid the need - for procedures to ensure uniqueness across, or even within, providers - and databases of the faceted entities for which the search is to be - performed. (See [DNS-Search] for further discussion.) - - While the discussion above includes very general comments about - attributes, it appears that only a very small number of attributes - would be needed. The list would almost certainly include country and - language for internationalization purposes. It might require - "charset" if we cannot agree on a character set and encoding, - although there are strong arguments for simply using ISO 10646 (also - known as Unicode or "UCS" (for Universal Character Set) [UNICODE], - [IS10646] coding in interchange. Trademark issues might motivate - "commercial" and "non-commercial" (or other) attributes if they would - be helpful in bypassing trademark problems. And applications to - resource location, such as those contemplated for Uniform Resource - Identifiers (URIs) [RFC2396, RFC3305] or the Service Location - Protocol [RFC2608], might argue for a few other attributes (as - outlined above). - -4. Internationalization - - Much of the thinking underlying this document was driven by - considerations of internationalizing the DNS or, more specifically, - providing access to the functions of the DNS from languages and - naming systems that cannot be accurately expressed in the traditional - DNS subset of ASCII. Much of the relevant work was done in the - IETF's "Internationalized Domain Names" Working Group (IDN-WG), - although this document also draws on extensive parallel discussions - in other forums. This section contains an evaluation of what was - learned as an "internationalized DNS" or "multilingual DNS" was - explored and suggests future steps based on that evaluation. - - When the IDN-WG was initiated, it was obvious to several of the - participants that its first important task was an undocumented one: - to increase the understanding of the complexities of the problem - sufficiently that naive solutions could be rejected and people could - go to work on the harder problems. The IDN-WG clearly accomplished - that task. The beliefs that the problems were simple, and in the - corresponding simplistic approaches and their promises of quick and - painless deployment, effectively disappeared as the WG's efforts - matured. - - - - -Klensin Informational [Page 15] - -RFC 3467 Role of the Domain Name System (DNS) February 2003 - - - Some of the lessons learned from increased understanding and the - dissipation of naive beliefs should be taken as cautions by the wider - community: the problems are not simple. Specifically, extracting - small elements for solution rather than looking at whole systems, may - result in obscuring the problems but not solving any problem that is - worth the trouble. - -4.1 ASCII Isn't Just Because of English - - The hostname rules chosen in the mid-70s weren't just "ASCII because - English uses ASCII", although that was a starting point. We have - discovered that almost every other script (and even ASCII if we - permit the rest of the characters specified in the ISO 646 - International Reference Version) is more complex than hostname- - restricted-ASCII (the "LDH" form, see section 1.1). And ASCII isn't - sufficient to completely represent English -- there are several words - in the language that are correctly spelled only with characters or - diacritical marks that do not appear in ASCII. With a broader - selection of scripts, in some examples, case mapping works from one - case to the other but is not reversible. In others, there are - conventions about alternate ways to represent characters (in the - language, not [only] in character coding) that work most of the time, - but not always. And there are issues in coding, with Unicode/10646 - providing different ways to represent the same character - ("character", rather than "glyph", is used deliberately here). And, - in still others, there are questions as to whether two glyphs - "match", which may be a distance-function question, not one with a - binary answer. The IETF approach to these problems is to require - pre-matching canonicalization (see the "stringprep" discussion - below). - - The IETF has resisted the temptations to either try to specify an - entirely new coded character set, or to pick and choose Unicode/10646 - characters on a per-character basis rather than by using well-defined - blocks. While it may appear that a character set designed to meet - Internet-specific needs would be very attractive, the IETF has never - had the expertise, resources, and representation from critically- - important communities to actually take on that job. Perhaps more - important, a new effort might have chosen to make some of the many - complex tradeoffs differently than the Unicode committee did, - producing a code with somewhat different characteristics. But there - is no evidence that doing so would produce a code with fewer problems - and side-effects. It is much more likely that making tradeoffs - differently would simply result in a different set of problems, which - would be equally or more difficult. - - - - - - -Klensin Informational [Page 16] - -RFC 3467 Role of the Domain Name System (DNS) February 2003 - - -4.2 The "ASCII Encoding" Approaches - - While the DNS can handle arbitrary binary strings without known - internal problems (see [RFC2181]), some restrictions are imposed by - the requirement that text be interpreted in a case-independent way - ([RFC1034], [RFC1035]). More important, most internet applications - assume the hostname-restricted "LDH" syntax that is specified in the - host table RFCs and as "prudent" in RFC 1035. If those assumptions - are not met, many conforming implementations of those applications - may exhibit behavior that would surprise implementors and users. To - avoid these potential problems, IETF internationalization work has - focused on "ASCII-Compatible Encodings" (ACE). These encodings - preserve the LDH conventions in the DNS itself. Implementations of - applications that have not been upgraded utilize the encoded forms, - while newer ones can be written to recognize the special codings and - map them into non-ASCII characters. These approaches are, however, - not problem-free even if human interface issues are ignored. Among - other issues, they rely on what is ultimately a heuristic to - determine whether a DNS label is to be considered as an - internationalized name (i.e., encoded Unicode) or interpreted as an - actual LDH name in its own right. And, while all determinations of - whether a particular query matches a stored object are traditionally - made by DNS servers, the ACE systems, when combined with the - complexities of international scripts and names, require that much of - the matching work be separated into a separate, client-side, - canonicalization or "preparation" process before the DNS matching - mechanisms are invoked [STRINGPREP]. - -4.3 "Stringprep" and Its Complexities - - As outlined above, the model for avoiding problems associated with - putting non-ASCII names in the DNS and elsewhere evolved into the - principle that strings are to be placed into the DNS only after being - passed through a string preparation function that eliminates or - rejects spurious character codes, maps some characters onto others, - performs some sequence canonicalization, and generally creates forms - that can be accurately compared. The impact of this process on - hostname-restricted ASCII (i.e., "LDH") strings is trivial and - essentially adds only overhead. For other scripts, the impact is, of - necessity, quite significant. - - Although the general notion underlying stringprep is simple, the many - details are quite subtle and the associated tradeoffs are complex. A - design team worked on it for months, with considerable effort placed - into clarifying and fine-tuning the protocol and tables. Despite - general agreement that the IETF would avoid getting into the business - of defining character sets, character codings, and the associated - conventions, the group several times considered and rejected special - - - -Klensin Informational [Page 17] - -RFC 3467 Role of the Domain Name System (DNS) February 2003 - - - treatment of code positions to more nearly match the distinctions - made by Unicode with user perceptions about similarities and - differences between characters. But there were intense temptations - (and pressures) to incorporate language-specific or country-specific - rules. Those temptations, even when resisted, were indicative of - parts of the ongoing controversy or of the basic unsuitability of the - DNS for fully internationalized names that are visible, - comprehensible, and predictable for end users. - - There have also been controversies about how far one should go in - these processes of preparation and transformation and, ultimately, - about the validity of various analogies. For example, each of the - following operations has been claimed to be similar to case-mapping - in ASCII: - - o stripping of vowels in Arabic or Hebrew - - o matching of "look-alike" characters such as upper-case Alpha in - Greek and upper-case A in Roman-based alphabets - - o matching of Traditional and Simplified Chinese characters that - represent the same words, - - o matching of Serbo-Croatian words whether written in Roman-derived - or Cyrillic characters - - A decision to support any of these operations would have implications - for other scripts or languages and would increase the overall - complexity of the process. For example, unless language-specific - information is somehow available, performing matching between - Traditional and Simplified Chinese has impacts on Japanese and Korean - uses of the same "traditional" characters (e.g., it would not be - appropriate to map Kanji into Simplified Chinese). - - Even were the IDN-WG's other work to have been abandoned completely - or if it were to fail in the marketplace, the stringprep and nameprep - work will continue to be extremely useful, both in identifying issues - and problem code points and in providing a reasonable set of basic - rules. Where problems remain, they are arguably not with nameprep, - but with the DNS-imposed requirement that its results, as with all - other parts of the matching and comparison process, yield a binary - "match or no match" answer, rather than, e.g., a value on a - similarity scale that can be evaluated by the user or by user-driven - heuristic functions. - - - - - - - -Klensin Informational [Page 18] - -RFC 3467 Role of the Domain Name System (DNS) February 2003 - - -4.4 The Unicode Stability Problem - - ISO 10646 basically defines only code points, and not rules for using - or comparing the characters. This is part of a long-standing - tradition with the work of what is now ISO/IEC JTC1/SC2: they have - performed code point assignments and have typically treated the ways - in which characters are used as beyond their scope. Consequently, - they have not dealt effectively with the broader range of - internationalization issues. By contrast, the Unicode Technical - Committee (UTC) has defined, in annexes and technical reports (see, - e.g., [UTR15]), some additional rules for canonicalization and - comparison. Many of those rules and conventions have been factored - into the "stringprep" and "nameprep" work, but it is not - straightforward to make or define them in a fashion that is - sufficiently precise and permanent to be relied on by the DNS. - - Perhaps more important, the discussions leading to nameprep also - identified several areas in which the UTC definitions are inadequate, - at least without additional information, to make matching precise and - unambiguous. In some of these cases, the Unicode Standard permits - several alternate approaches, none of which are an exact and obvious - match to DNS needs. That has left these sensitive choices up to - IETF, which lacks sufficient in-depth expertise, much less any - mechanism for deciding to optimize one language at the expense of - another. - - For example, it is tempting to define some rules on the basis of - membership in particular scripts, or for punctuation characters, but - there is no precise definition of what characters belong to which - script or which ones are, or are not, punctuation. The existence of - these areas of vagueness raises two issues: whether trying to do - precise matching at the character set level is actually possible - (addressed below) and whether driving toward more precision could - create issues that cause instability in the implementation and - resolution models for the DNS. - - The Unicode definition also evolves. Version 3.2 appeared shortly - after work on this document was initiated. It added some characters - and functionality and included a few minor incompatible code point - changes. IETF has secured an agreement about constraints on future - changes, but it remains to be seen how that agreement will work out - in practice. The prognosis actually appears poor at this stage, - since UTC chose to ballot a recent possible change which should have - been prohibited by the agreement (the outcome of the ballot is not - relevant, only that the ballot was issued rather than having the - result be a foregone conclusion). However, some members of the - community consider some of the changes between Unicode 3.0 and 3.1 - and between 3.1 and 3.2, as well as this recent ballot, to be - - - -Klensin Informational [Page 19] - -RFC 3467 Role of the Domain Name System (DNS) February 2003 - - - evidence of instability and that these instabilities are better - handled in a system that can be more flexible about handling of - characters, scripts, and ancillary information than the DNS. - - In addition, because the systems implications of internationalization - are considered out of scope in SC2, ISO/IEC JTC1 has assigned some of - those issues to its SC22/WG20 (the Internationalization working group - within the subcommittee that deals with programming languages, - systems, and environments). WG20 has historically dealt with - internationalization issues thoughtfully and in depth, but its status - has several times been in doubt in recent years. However, assignment - of these matters to WG20 increases the risk of eventual ISO - internationalization standards that specify different behavior than - the UTC specifications. - -4.5 Audiences, End Users, and the User Interface Problem - - Part of what has "caused" the DNS internationalization problem, as - well as the DNS trademark problem and several others, is that we have - stopped thinking about "identifiers for objects" -- which normal - people are not expected to see -- and started thinking about "names" - -- strings that are expected not only to be readable, but to have - linguistically-sensible and culturally-dependent meaning to non- - specialist users. - - Within the IETF, the IDN-WG, and sometimes other groups, avoided - addressing the implications of that transition by taking "outside our - scope -- someone else's problem" approaches or by suggesting that - people will just become accustomed to whatever conventions are - adopted. The realities of user and vendor behavior suggest that - these approaches will not serve the Internet community well in the - long term: - - o If we want to make it a problem in a different part of the user - interface structure, we need to figure out where it goes in order - to have proof of concept of our solution. Unlike vendors whose - sole [business] model is the selling or registering of names, the - IETF must produce solutions that actually work, in the - applications context as seen by the end user. - - o The principle that "they will get used to our conventions and - adapt" is fine if we are writing rules for programming languages - or an API. But the conventions under discussion are not part of a - semi-mathematical system, they are deeply ingrained in culture. - No matter how often an English-speaking American is told that the - Internet requires that the correct spelling of "colour" be used, - he or she isn't going to be convinced. Getting a French-speaker in - Lyon to use exactly the same lexical conventions as a French- - - - -Klensin Informational [Page 20] - -RFC 3467 Role of the Domain Name System (DNS) February 2003 - - - speaker in Quebec in order to accommodate the decisions of the - IETF or of a registrar or registry is just not likely. "Montreal" - is either a misspelling or an anglicization of a similar word with - an acute accent mark over the "e" (i.e., using the Unicode - character U+00E9 or one of its equivalents). But global agreement - on a rule that will determine whether the two forms should match - -- and that won't astonish end users and speakers of one language - or the other -- is as unlikely as agreement on whether - "misspelling" or "anglicization" is the greater travesty. - - More generally, it is not clear that the outcome of any conceivable - nameprep-like process is going to be good enough for practical, - user-level, use. In the use of human languages by humans, there are - many cases in which things that do not match are nonetheless - interpreted as matching. The Norwegian/Danish character that appears - in U+00F8 (visually, a lower case 'o' overstruck with a forward - slash) and the "o-umlaut" German character that appears in U+00F6 - (visually, a lower case 'o' with diaeresis (or umlaut)) are clearly - different and no matching program should yield an "equal" comparison. - But they are more similar to each other than either of them is to, - e.g., "e". Humans are able to mentally make the correction in - context, and do so easily, and they can be surprised if computers - cannot do so. Worse, there is a Swedish character whose appearance - is identical to the German o-umlaut, and which shares code point - U+00F6, but that, if the languages are known and the sounds of the - letters or meanings of words including the character are considered, - actually should match the Norwegian/Danish use of U+00F8. - - This text uses examples in Roman scripts because it is being written - in English and those examples are relatively easy to render. But one - of the important lessons of the discussions about domain name - internationalization in recent years is that problems similar to - those described above exist in almost every language and script. - Each one has its idiosyncrasies, and each set of idiosyncracies is - tied to common usage and cultural issues that are very familiar in - the relevant group, and often deeply held as cultural values. As - long as a schoolchild in the US can get a bad grade on a spelling - test for using a perfectly valid British spelling, or one in France - or Germany can get a poor grade for leaving off a diacritical mark, - there are issues with the relevant language. Similarly, if children - in Egypt or Israel are taught that it is acceptable to write a word - with or without vowels or stress marks, but that, if those marks are - included, they must be the correct ones, or a user in Korea is - potentially offended or astonished by out-of-order sequences of Jamo, - systems based on character-at-a-time processing and simplistic - matching, with no contextual information, are not going to satisfy - user needs. - - - - -Klensin Informational [Page 21] - -RFC 3467 Role of the Domain Name System (DNS) February 2003 - - - Users are demanding solutions that deal with language and culture. - Systems of identifier symbol-strings that serve specialists or - computers are, at best, a solution to a rather different (and, at the - time this document was written, somewhat ill-defined), problem. The - recent efforts have made it ever more clear that, if we ignore the - distinction between the user requirements and narrowly-defined - identifiers, we are solving an insufficient problem. And, - conversely, the approaches that have been proposed to approximate - solutions to the user requirement may be far more complex than simple - identifiers require. - -4.6 Business Cards and Other Natural Uses of Natural Languages - - Over the last few centuries, local conventions have been established - in various parts of the world for dealing with multilingual - situations. It may be helpful to examine some of these. For - example, if one visits a country where the language is different from - ones own, business cards are often printed on two sides, one side in - each language. The conventions are not completely consistent and the - technique assumes that recipients will be tolerant. Translations of - names or places are attempted in some situations and transliterations - in others. Since it is widely understood that exact translations or - transliterations are often not possible, people typically smile at - errors, appreciate the effort, and move on. - - The DNS situation differs from these practices in at least two ways. - Since a global solution is required, the business card would need a - number of sides approximating the number of languages in the world, - which is probably impossible without violating laws of physics. More - important, the opportunities for tolerance don't exist: the DNS - requires a exact match or the lookup fails. - -4.7 ASCII Encodings and the Roman Keyboard Assumption - - Part of the argument for ACE-based solutions is that they provide an - escape for multilingual environments when applications have not been - upgraded. When an older application encounters an ACE-based name, - the assumption is that the (admittedly ugly) ASCII-coded string will - be displayed and can be typed in. This argument is reasonable from - the standpoint of mixtures of Roman-based alphabets, but may not be - relevant if user-level systems and devices are involved that do not - support the entry of Roman-based characters or which cannot - conveniently render such characters. Such systems are few in the - world today, but the number can reasonably be expected to rise as the - Internet is increasingly used by populations whose primary concern is - with local issues, local information, and local languages. It is, - - - - - -Klensin Informational [Page 22] - -RFC 3467 Role of the Domain Name System (DNS) February 2003 - - - for example, fairly easy to imagine populations who use Arabic or - Thai scripts and who do not have routine access to scripts or input - devices based on Roman-derived alphabets. - -4.8 Intra-DNS Approaches for "Multilingual Names" - - It appears, from the cases above and others, that none of the intra- - DNS-based solutions for "multilingual names" are workable. They rest - on too many assumptions that do not appear to be feasible -- that - people will adapt deeply-entrenched language habits to conventions - laid down to make the lives of computers easy; that we can make - "freeze it now, no need for changes in these areas" decisions about - Unicode and nameprep; that ACE will smooth over applications - problems, even in environments without the ability to key or render - Roman-based glyphs (or where user experience is such that such glyphs - cannot easily be distinguished from each other); that the Unicode - Consortium will never decide to repair an error in a way that creates - a risk of DNS incompatibility; that we can either deploy EDNS - [RFC2671] or that long names are not really important; that Japanese - and Chinese computer users (and others) will either give up their - local or IS 2022-based character coding solutions (for which addition - of a large fraction of a million new code points to Unicode is almost - certainly a necessary, but probably not sufficient, condition) or - build leakproof and completely accurate boundary conversion - mechanisms; that out of band or contextual information will always be - sufficient for the "map glyph onto script" problem; and so on. In - each case, it is likely that about 80% or 90% of cases will work - satisfactorily, but it is unlikely that such partial solutions will - be good enough. For example, suppose someone can spell her name 90% - correctly, or a company name is matched correctly 80% of the time but - the other 20% of attempts identify a competitor: are either likely to - be considered adequate? - -5. Search-based Systems: The Key Controversies - - For many years, a common response to requirements to locate people or - resources on the Internet has been to invoke the term "directory". - While an in-depth analysis of the reasons would require a separate - document, the history of failure of these invocations has given - "directory" efforts a bad reputation. The effort proposed here is - different from those predecessors for several reasons, perhaps the - most important of which is that it focuses on a fairly-well- - understood set of problems and needs, rather than on finding uses for - a particular technology. - - As suggested in some of the text above, it is an open question as to - whether the needs of the community would be best served by a single - (even if functionally, and perhaps administratively, distributed) - - - -Klensin Informational [Page 23] - -RFC 3467 Role of the Domain Name System (DNS) February 2003 - - - directory with universal applicability, a single directory that - supports locally-tailored search (and, most important, matching) - functions, or multiple, locally-determined, directories. Each has - its attractions. Any but the first would essentially prevent - reverse-mapping (determination of the user-visible name of the host - or resource from target information such as an address or DNS name). - But reverse mapping has become less useful over the years --at least - to users -- as more and more names have been associated with many - host addresses and as CIDR [CIDR] has proven problematic for mapping - smaller address blocks to meaningful names. - - Locally-tailored searches and mappings would permit national - variations on interpretation of which strings matched which other - ones, an arrangement that is especially important when different - localities apply different rules to, e.g., matching of characters - with and without diacriticals. But, of course, this implies that a - URL may evaluate properly or not depending on either settings on a - client machine or the network connectivity of the user. That is not, - in general, a desirable situation, since it implies that users could - not, in the general case, share URLs (or other host references) and - that a particular user might not be able to carry references from one - host or location to another. - - And, of course, completely separate directories would permit - translation and transliteration functions to be embedded in the - directory, giving much of the Internet a different appearance - depending on which directory was chosen. The attractions of this are - obvious, but, unless things were very carefully designed to preserve - uniqueness and precise identities at the right points (which may or - may not be possible), such a system would have many of the - difficulties associated with multiple DNS roots. - - Finally, a system of separate directories and databases, if coupled - with removal of the DNS-imposed requirement for unique names, would - largely eliminate the need for a single worldwide authority to manage - the top of the naming hierarchy. - -6. Security Considerations - - The set of proposals implied by this document suggests an interesting - set of security issues (i.e., nothing important is ever easy). A - directory system used for locating network resources would presumably - need to be as carefully protected against unauthorized changes as the - DNS itself. There also might be new opportunities for problems in an - arrangement involving two or more (sub)layers, especially if such a - system were designed without central authority or uniqueness of - names. It is uncertain how much greater those risks would be as - compared to a DNS lookup sequence that involved looking up one name, - - - -Klensin Informational [Page 24] - -RFC 3467 Role of the Domain Name System (DNS) February 2003 - - - getting back information, and then doing additional lookups - potentially in different subtrees. That multistage lookup will often - be the case with, e.g., NAPTR records [RFC 2915] unless additional - restrictions are imposed. But additional steps, systems, and - databases almost certainly involve some additional risks of - compromise. - -7. References - -7.1 Normative References - - None - -7.2 Explanatory and Informative References - - [Albitz] Any of the editions of Albitz, P. and C. Liu, DNS and - BIND, O'Reilly and Associates, 1992, 1997, 1998, 2001. - - [ASCII] American National Standards Institute (formerly United - States of America Standards Institute), X3.4, 1968, - "USA Code for Information Interchange". ANSI X3.4-1968 - has been replaced by newer versions with slight - modifications, but the 1968 version remains definitive - for the Internet. Some time after ASCII was first - formulated as a standard, ISO adopted international - standard 646, which uses ASCII as a base. IS 646 - actually contained two code tables: an "International - Reference Version" (often referenced as ISO 646-IRV) - which was essentially identical to the ASCII of the - time, and a "Basic Version" (ISO 646-BV), which - designates a number of character positions for - national use. - - [CIDR] Fuller, V., Li, T., Yu, J. and K. Varadhan, "Classless - Inter-Domain Routing (CIDR): an Address Assignment and - Aggregation Strategy", RFC 1519, September 1993. - - Eidnes, H., de Groot, G. and P. Vixie, "Classless IN- - ADDR.ARPA delegation", RFC 2317, March 1998. - - [COM-SIZE] Size information supplied by Verisign Global Registry - Services (the zone administrator, or "registry - operator", for COM, see [REGISTRAR], below) to ICANN, - third quarter 2002. - - [DNS-Search] Klensin, J., "A Search-based access model for the - DNS", Work in Progress. - - - - -Klensin Informational [Page 25] - -RFC 3467 Role of the Domain Name System (DNS) February 2003 - - - [FINGER] Zimmerman, D., "The Finger User Information Protocol", - RFC 1288, December 1991. - - Harrenstien, K., "NAME/FINGER Protocol", RFC 742, - December 1977. - - [IAB-OPES] Floyd, S. and L. Daigle, "IAB Architectural and Policy - Considerations for Open Pluggable Edge Services", RFC - 3238, January 2002. - - [IQUERY] Lawrence, D., "Obsoleting IQUERY", RFC 3425, November - 2002. - - [IS646] ISO/IEC 646:1991 Information technology -- ISO 7-bit - coded character set for information interchange - - [IS10646] ISO/IEC 10646-1:2000 Information technology -- - Universal Multiple-Octet Coded Character Set (UCS) -- - Part 1: Architecture and Basic Multilingual Plane and - ISO/IEC 10646-2:2001 Information technology -- - Universal Multiple-Octet Coded Character Set (UCS) -- - Part 2: Supplementary Planes - - [MINC] The Multilingual Internet Names Consortium, - http://www.minc.org/ has been an early advocate for - the importance of expansion of DNS names to - accommodate non-ASCII characters. Some of their - specific proposals, while helping people to understand - the problems better, were not compatible with the - design of the DNS. - - [NAPTR] Mealling, M. and R. Daniel, "The Naming Authority - Pointer (NAPTR) DNS Resource Record", RFC 2915, - September 2000. - - Mealling, M., "Dynamic Delegation Discovery System - (DDDS) Part One: The Comprehensive DDDS", RFC 3401, - October 2002. - - Mealling, M., "Dynamic Delegation Discovery System - (DDDS) Part Two: The Algorithm", RFC 3402, October - 2002. - - Mealling, M., "Dynamic Delegation Discovery System - (DDDS) Part Three: The Domain Name System (DNS) - Database", RFC 3403, October 2002. - - - - - -Klensin Informational [Page 26] - -RFC 3467 Role of the Domain Name System (DNS) February 2003 - - - [REGISTRAR] In an early stage of the process that created the - Internet Corporation for Assigned Names and Numbers - (ICANN), a "Green Paper" was released by the US - Government. That paper introduced new terminology - and some concepts not needed by traditional DNS - operations. The term "registry" was applied to the - actual operator and database holder of a domain - (typically at the top level, since the Green Paper was - little concerned with anything else), while - organizations that marketed names and made them - available to "registrants" were known as "registrars". - In the classic DNS model, the function of "zone - administrator" encompassed both registry and registrar - roles, although that model did not anticipate a - commercial market in names. - - [RFC625] Kudlick, M. and E. Feinler, "On-line hostnames - service", RFC 625, March 1974. - - [RFC734] Crispin, M., "SUPDUP Protocol", RFC 734, October 1977. - - [RFC811] Harrenstien, K., White, V. and E. Feinler, "Hostnames - Server", RFC 811, March 1982. - - [RFC819] Su, Z. and J. Postel, "Domain naming convention for - Internet user applications", RFC 819, August 1982. - - [RFC830] Su, Z., "Distributed system for Internet name - service", RFC 830, October 1982. - - [RFC882] Mockapetris, P., "Domain names: Concepts and - facilities", RFC 882, November 1983. - - [RFC883] Mockapetris, P., "Domain names: Implementation - specification", RFC 883, November 1983. - - [RFC952] Harrenstien, K, Stahl, M. and E. Feinler, "DoD - Internet host table specification", RFC 952, October - 1985. - - [RFC953] Harrenstien, K., Stahl, M. and E. Feinler, "HOSTNAME - SERVER", RFC 953, October 1985. - - [RFC1034] Mockapetris, P., "Domain names, Concepts and - facilities", STD 13, RFC 1034, November 1987. - - - - - - -Klensin Informational [Page 27] - -RFC 3467 Role of the Domain Name System (DNS) February 2003 - - - [RFC1035] Mockapetris, P., "Domain names - implementation and - specification", STD 13, RFC 1035, November 1987. - - [RFC1591] Postel, J., "Domain Name System Structure and - Delegation", RFC 1591, March 1994. - - [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS - Specification", RFC 2181, July 1997. - - [RFC2295] Holtman, K. and A. Mutz, "Transparent Content - Negotiation in HTTP", RFC 2295, March 1998 - - [RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, - "Uniform Resource Identifiers (URI): Generic Syntax", - RFC 2396, August 1998. - - [RFC2608] Guttman, E., Perkins, C., Veizades, J. and M. Day, - "Service Location Protocol, Version 2", RFC 2608, June - 1999. - - [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC - 2671, August 1999. - - [RFC2825] IAB, Daigle, L., Ed., "A Tangled Web: Issues of I18N, - Domain Names, and the Other Internet protocols", RFC - 2825, May 2000. - - [RFC2826] IAB, "IAB Technical Comment on the Unique DNS Root", - RFC 2826, May 2000. - - [RFC2972] Popp, N., Mealling, M., Masinter, L. and K. Sollins, - "Context and Goals for Common Name Resolution", RFC - 2972, October 2000. - - [RFC3305] Mealling, M. and R. Denenberg, Eds., "Report from the - Joint W3C/IETF URI Planning Interest Group: Uniform - Resource Identifiers (URIs), URLs, and Uniform - Resource Names (URNs): Clarifications and - Recommendations", RFC 3305, August 2002. - - [RFC3439] Bush, R. and D. Meyer, "Some Internet Architectural - Guidelines and Philosophy", RFC 3439, December 2002. - - [Seng] Seng, J., et al., Eds., "Internationalized Domain - Names: Registration and Administration Guideline for - Chinese, Japanese, and Korean", Work in Progress. - - - - - -Klensin Informational [Page 28] - -RFC 3467 Role of the Domain Name System (DNS) February 2003 - - - [STRINGPREP] Hoffman, P. and M. Blanchet, "Preparation of - Internationalized Strings (stringprep)", RFC 3454, - December 2002. - - The particular profile used for placing - internationalized strings in the DNS is called - "nameprep", described in Hoffman, P. and M. Blanchet, - "Nameprep: A Stringprep Profile for Internationalized - Domain Names", Work in Progress. - - [TELNET] Postel, J. and J. Reynolds, "Telnet Protocol - Specification", STD 8, RFC 854, May 1983. - - Postel, J. and J. Reynolds, "Telnet Option - Specifications", STD 8, RFC 855, May 1983. - - [UNICODE] The Unicode Consortium, The Unicode Standard, Version - 3.0, Addison-Wesley: Reading, MA, 2000. Update to - version 3.1, 2001. Update to version 3.2, 2002. - - [UTR15] Davis, M. and M. Duerst, "Unicode Standard Annex #15: - Unicode Normalization Forms", Unicode Consortium, - March 2002. An integral part of The Unicode Standard, - Version 3.1.1. Available at - (http://www.unicode.org/reports/tr15/tr15-21.html). - - [WHOIS] Harrenstien, K, Stahl, M. and E. Feinler, - "NICNAME/WHOIS", RFC 954, October 1985. - - [WHOIS-UPDATE] Gargano, J. and K. Weiss, "Whois and Network - Information Lookup Service, Whois++", RFC 1834, August - 1995. - - Weider, C., Fullton, J. and S. Spero, "Architecture of - the Whois++ Index Service", RFC 1913, February 1996. - - Williamson, S., Kosters, M., Blacka, D., Singh, J. and - K. Zeilstra, "Referral Whois (RWhois) Protocol V1.5", - RFC 2167, June 1997; - - Daigle, L. and P. Faltstrom, "The - application/whoispp-query Content-Type", RFC 2957, - October 2000. - - Daigle, L. and P. Falstrom, "The application/whoispp- - response Content-type", RFC 2958, October 2000. - - - - - -Klensin Informational [Page 29] - -RFC 3467 Role of the Domain Name System (DNS) February 2003 - - - [X29] International Telecommuncations Union, "Recommendation - X.29: Procedures for the exchange of control - information and user data between a Packet - Assembly/Disassembly (PAD) facility and a packet mode - DTE or another PAD", December 1997. - -8. Acknowledgements - - Many people have contributed to versions of this document or the - thinking that went into it. The author would particularly like to - thank Harald Alvestrand, Rob Austein, Bob Braden, Vinton Cerf, Matt - Crawford, Leslie Daigle, Patrik Faltstrom, Eric A. Hall, Ted Hardie, - Paul Hoffman, Erik Nordmark, and Zita Wenzel for making specific - suggestions and/or challenging the assumptions and presentation of - earlier versions and suggesting ways to improve them. - -9. Author's Address - - John C. Klensin - 1770 Massachusetts Ave, #322 - Cambridge, MA 02140 - - EMail: klensin+srch@jck.com - - A mailing list has been initiated for discussion of the topics - discussed in this document, and closely-related issues, at - ietf-irnss@lists.elistx.com. See http://lists.elistx.com/archives/ - for subscription and archival information. - - - - - - - - - - - - - - - - - - - - - - - -Klensin Informational [Page 30] - -RFC 3467 Role of the Domain Name System (DNS) February 2003 - - -10. Full Copyright Statement - - Copyright (C) The Internet Society (2003). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - - - - - - - - - - - - - -Klensin Informational [Page 31] - |