GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc3467

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):
  1. 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
  1. accept client-site attributes and utilize them in the search

process, or

  1. 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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc3467.txt · Last modified: 2003/02/27 18:09 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki