RFC 3467

Role of the Domain Name System (DNS)

📅 published March 2003, from ietf

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 (C) The Internet Society (2003). All Rights Reserved. 💅

Abstract ✨

okay so this doc takes a look at what the DNS was originally built to do 🧚 and then compares that to all the extra stuff people have been piling onto it lately. it's giving "the DNS is being asked to do EVERYTHING" 😭 the author then sketches out an alternative framework for taking some of that pressure off the DNS. and to be clear, this isn't a proposed solution, it's more of a strong nudge that it's time to start thinking bigger about the problems we're running into and how we might fix 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
   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 🕰️

1.1. Context for DNS Development 💜

okay so the DNS was basically built as a glow-up for the older "host table" system 💅 both were meant to give network resources names that feel more abstract than their IP addresses (see, e.g., [RFC625], [RFC811], [RFC819], [RFC830], [RFC882]). over time the DNS turned into a kind of database of convenience for the Internet, and everyone kept proposing new features for it. only some of those features actually landed 🙈 and honestly, a lot of people use the DNS just because it's already there and everywhere, not because its structure, features, and content are actually right for what they're trying to do. this doc looks back at the DNS's history, including some of those newer uses. then it argues that this overloading is often the wrong move. instead, the DNS should get backup from systems that actually fit the jobs, and it lays out a framework and reasoning for one of those systems 🧚

the author is upfront that some of this is a bit revisionist 🤭 good design often needs the designers to have a sixth sense about what's coming, and the reasons behind some choices never got written down because nobody could put them into words at the time. so this part reconstructs some decisions about the Internet's main namespace (the "Class=IN" DNS) with hindsight 🔮 the historical reasons for a lot of choices were barely documented back then, and people remember things differently, so this is just one story. there are probably other stories about how the DNS got to where it is now, but those versions don't undo the inferences and conclusions here 🫶

this doc assumes you already get the terminology from RFC 1034 [RFC1034] or any decent DNS tutorial (see, e.g., [Albitz]) 📖

1.1. Context for DNS Development 💜

Wait, that heading got doubled up in my last pass, so let me fix the numbering. The subsection below is 1.1, and it carries on with the host table history. ✨

okay so during the whole post-startup stretch of the ARPANET, and pretty much the first decade or so of the Internet, the list of host names and how they mapped to addresses lived in a frequently-updated "host table" [RFC625], [RFC811], [RFC952]. the names were limited to a subset of ASCII [ASCII], picked to dodge ambiguity in printed form, to play nicely with systems using other character codings (EBCDIC, looking at you 👀), and to stay out of the "national use" code positions of ISO 646 [IS646]. those restrictions were later called the "LDH" rules for "letter-digit-hyphen", which is the set of allowed characters 🔤 the table was just a list in a common format that everyone eventually agreed on, and sites were expected to grab new copies and install them pretty often. the host tables were introduced to:

  • Get rid of the need for people to remember host numbers (addresses). Even though the phone system seemed to suggest otherwise, numeric numbering, including the numeric host number strategy, did not (and does not) work well beyond a (large) handful of hosts. 🙃
  • Provide stability when addresses changed. Addresses, to some degree in the ARPANET and even more so on today's Internet, depend on network topology and routing, so they often had to change whenever connectivity or topology changed. Names could stay stable even while addresses moved around 🦋
  • Provide the capability to have multiple addresses associated with a given host to reflect different types of connectivity and topology. Using names instead of explicit addresses meant users and other hosts didn't have to track all those host numbers and addresses, or deal with the topology stuff needed to pick one over the others 💅

after several years of the host table approach, the community decided that model didn't scale well enough and wouldn't properly support new service variations 😬 a bunch of discussions and meetings pulled together lots of ideas and half-finished proposals. the DNS was the result of that effort 🎉 it kept evolving during the design and early implementation period, and a number of documents recorded the changes (see [RFC819], [RFC830], and [RFC1034]) 📝

the goals for the DNS included:

  • Preserving what the host table setups could do (especially unique, unambiguous host names) 💖
  • Making room for adding more services (for example, the special record types for email routing that showed up right after the DNS was introduced) 📬
  • Building a robust, hierarchical, distributed name lookup system to get the other goals done 🌈

the DNS design also allowed name administration to be distributed, instead of requiring every host to be entered into one single central table managed by a central authority 🫶

Part 1 of 10. More parts are coming, so stay tuned, bestie! 💫

1.2. Review of the DNS and Its Role as Designed ✨

okay so the DNS was designed to identify network resources 🌸 people did float ideas about putting personal names and email addresses in there, but it was never mainly meant to identify people, brands, etc. 🙈 the design was super flexible though, so it could take new data types and structures, either by adding new record types to the initial "INternet" class or possibly by introducing new classes. 💅 nobody could predict what those future extensions would need, so the fields were built to hold any (binary) information, not just the restricted text forms of the host table. iconic design choice 👑

ngl, the DNS as it actually gets used is super tangled up with the applications and application protocols that rely on it, and often at a pretty low level 🧚

here's the tea 🫖 even though the protocols and data structures can handle any binary representation, DNS names as used were never even full unrestricted ASCII. they were a very restricted subset, and that subset comes from the original host table naming rules 💖 part of the reason for picking that subset was human factors, especially wanting to get rid of possible ambiguities in an international context. so character codes that got interpreted differently around the world were left out, the underscore got banned, and case distinctions were eliminated because they were confusing (the underscore especially, since it looks like the hyphen) when people wrote or read them, and so on 🎀 these choices look a lot like the ones behind similarly restricted character sets used as protocol elements in many ITU and ISO protocols (cf. [X29]) 🦋

another assumption was a high ratio of physical hosts to second level domains. more generally, the system was expected to be deeply hierarchical, with most systems (and names) sitting at the third level or below, and a very large percentage of the total names representing physical hosts 🍓 some domains do follow this model! lots of university and corporate domains use pretty deep hierarchies, and so do a few country-oriented top level domains ("ccTLDs") ✨ the "US." domain has historically been a really good example of the deeply hierarchical approach 🌈

but then, by 1998, comparing several efforts to survey the DNS showed a count of SOA records that approached (and may have passed) the number of distinct hosts 😭 looking at it another way, the number of delegated domains on the Internet seems to be heading toward, or past, the number of hosts (or at least the number of hosts able to provide services to others on the network) 💀 this presumably comes from synonyms or aliases that map a bunch of names onto a smaller number of hosts 🫶 experience so far shows the DNS is robust enough, given contemporary machines as servers and current bandwidth norms, to keep working reasonably well even when those historical assumptions aren't met. for example, there's a flat structure under ".COM" with well over ten million delegated subdomains [COMSIZE], and it's still standing! 👑 still, it's worth remembering that the system could have been designed to work optimally with a flat structure (and very large zones) instead of a deeply hierarchical one, and it wasn't 🔥

similarly, even though there was some early speculation about entering people's names and email addresses into the DNS directly (e.g., see [RFC1034]), email addresses on the Internet have kept the original, pre-DNS, "user (or mailbox) at location" format, rather than a flatter or strictly dot-separated one 💜 in that case, "location" is a reference to a host. the one exception, at least in the "IN" class, is one field of the SOA record 🎀

the DNS architecture itself, plus the two-level (host name and mailbox name) setup for email and similar functions (e.g., see the finger protocol [FINGER]), both also anticipated a relatively high ratio of users to actual hosts 🦋 RFC 1034 noted that the DNS was expected to grow to be proportional to the number of users (section 2.3), but honestly it's never been clear that the DNS was seriously designed for, or could scale to, the number of users (or, more recently, products or document objects) rather than the number of physical hosts 🙈

just like the host table before it, the DNS gave names critical uniqueness and universal accessibility, as part of the overall "single internet" and "end to end" models (cf. [RFC2826]) 🌸 however, there are lots of signs that, as new uses evolved and the original assumptions got abused (if not straight-up violated), the system was being stretched to, or beyond, its practical limits 😭

the original design effort that led to the DNS looked at 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. some of the participants feared those limitations might cause future problems, and this document basically takes the position that they were probably correct 💅 on the other hand, directory technology and implementations have evolved a lot in the years since, so it may be time to revisit the assumptions. that could happen in the context of the two- (or more) level mechanism this document contemplates 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 the scaling of the Internet, including optimal accessibility to content), the web's decision to use "A record" domain names directly in URLs, rather than some system of indirection, has turned out to be a serious mistake in several respects 💀 convenience of typing, plus the desire to make domain names out of easily-remembered product names, flattened the DNS. now a lot of people perceive that second-level names under COM (or, in some countries, second- or third-level names under the relevant ccTLD) are all that's meaningful 🙈 that perception got reinforced by some domain name registrars [REGISTRAR] who were eager to "sell" additional names 🤑 and of course, the idea that you needed a second-level (or even top-level) domain per product, instead of names tied to a (usually organizational) collection of network resources, caused a rapid acceleration in the number of names being registered 😭 that acceleration clearly benefited registrars charging per name, "cybersquatters", and others in the business of "selling" names, but it hasn't obviously benefited the Internet as a whole 💅

this emphasis on second-level domain names also created a problem for the trademark community 🎀 the Internet is international, and names are being populated in a flat and unqualified space, so similarly-named entities end up in conflict even when there would normally be no chance of confusing them in the marketplace 🦋 the problem seems unsolvable except by choosing between draconian measures. those might include major changes to the legislation and conventions that govern disputes over "names" and "marks" 👑 or they might lead to a situation where the "rights" to a name typically aren't settled using the subtle, traditional product (or industry) type and geopolitical scope rules of the trademark system 💔 instead, they'd depend 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 🥲 that raises not only big equity issues, but also the risk of backlash, as the numerous small players are forced to give up names they find attractive and adopt less-desirable naming conventions 🌧️

separate from these sociopolitical problems, content distribution issues have made it clear that an organization should be able to have copies of the data it wants to make available distributed around the network. then a user who asks for the information by name would get the topologically-closest copy 🧚 this isn't possible with simple, as-designed use of the DNS, because 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, the business models that go with them) have popped up to work around these problems, including intercepting and altering DNS requests so they point to other locations 🌀

there are still more implications being discovered and evaluated 🔍

approaches that involve intercepting DNS queries and rewriting DNS names (or otherwise altering the resolution process based on the user's topological location) seem to risk disrupting end-to-end applications in the general case 🚧 they also raise many of the issues the IAB discussed in [IAB-OPES] 🫶 these problems happen even if the rewriting machinery comes with extra workarounds for particular applications. for example, security associations and applications that need to identify "the same host" often run into trouble if DNS names or other references get changed inside the network without the applications that are trying to invoke the associated services taking part 🔐 it's giving fragile, honestly 💜

1.4 Internet Applications Protocols and Their Evolution ✨

At the applications level, hardly any of the protocols that are actually in active, widespread use on the Internet reflect contemporary knowledge in computer science or human factors, or the experience gathered through deployment and use 🫠. Instead, protocols tend to get deployed at a just-past-prototype level, usually with the kinds of expedient compromises you always see in prototypes 🙈. If they prove useful, the nature of the network lets them spread super fast (like, they fill a vacuum, even if it's a vacuum nobody knew was there 🦋). But once that vacuum is filled, the installed base has its own inertia 💅. Unless the design is so seriously broken that nobody can use it effectively (or there's a widely-perceived sense of impending disaster unless the protocol gets replaced), future developments have to stay backward compatible and work around problematic characteristics, rather than getting to benefit from a redesign informed by experience 😭. Applications that are "almost good enough" block the development and deployment of high-quality replacements 💀.

The DNS is both an illustration of this pessimistic picture and an exception to parts of it 🎀. It was a second-generation development, and the host table system was seen as being at the end of its useful life 🧚. There was a serious attempt to reflect the computing state of the art at the time 👑. However, deployment was much slower than anyone expected (and really painful for many sites), and some fixed deadlines from a central network administration were needed just for deployment to happen at all 😩. Those deadlines were relaxed several times, though. Replacing it now, in order to add functionality, while it keeps performing its core functions at least reasonably well, would presumably be extremely difficult 🥺.

There are many, maybe obvious, examples of this 🌸. Despite many known deficiencies and weaknesses in their definitions, the "finger" and "whois" [WHOIS] protocols have not been replaced (even though there have been many efforts to update or replace the latter [WHOIS-UPDATE]) 🙃. The Telnet protocol and its many options pushed 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 their advocates considered much better have failed 📧. And, more recently and below the applications level, there's some reason to believe this resistance to change has been one of the factors slowing down IPv6 deployment 🌈.

2. Signs of DNS Overloading ✨

okay bestie, so the history we just went through shows some spots where the DNS is kinda overloaded 🫠 (semantically, not in the "it can't resolve names anymore" way). Despite that, DNS performance and reliability are still in an acceptable range 💅. There's very little evidence of serious performance degradation. Recent proposals and mechanisms for handling overloading and scaling issues mostly focus on patching or working around the limits that show up when the DNS gets used for out-of-design functions 🔧, instead of dramatically rethinking the DNS design or those uses. But the number of these issues popping up at about the same time may argue for exactly that kind of rethink 🧠, and not just for piling on complexity and trying to tweak the design bit by bit (see, for example, the discussion of simplicity in section 2 of [RFC3439]).

For example:

  • 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 🙃.
  • 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) 🏠.
  • 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 📏.
  • 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 🍕🚗.
  • 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 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 😬.

  • 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 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) 🀄.
  • 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 🌏.
  • 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 🧩.
  • 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 📂.
  • 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 🥲.

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 🔍

okay so the DNS rules and everything we just talked about are basically begging for an intermediate protocol mechanism, bestie 🫶 we're calling it a "search layer" (or a "searchable system") 💅. "Directory" and "directory system" get used interchangeably with "searchable system" in this doc, though "searchable system" is way more precise ✨. A search layer would do a two (or more) stage lookup, kinda like those internationalized-names proposals for the DNS (see section 4) 🌸. The twist is that every stage except the last one searches other systems instead of looking up identifiers in the DNS itself 🧚. Once you do that, you can relax a bunch of constraints and end up with a more capable, comprehensive system overall 🦋 iconic.

Ultimately, a lot of domain name problems come from people trying to use the DNS as a directory 💀. When this was written, there wasn't enough pressure or demand to justify a change, but it was already super clear that as a directory system the DNS is a good deal less than ideal 🙈. This doc argues there really is a need for a directory system, and that the right answer to a searchable system need is an actual searchable system, not a pile of DNS patches, kludges, or workarounds 💅✨.

Here's the tea, point by point 🍓:

  • A directory system would not require imposing particular length limits on names. 🎀
  • A directory system could explicitly associate attributes, like language and country, with a name, without needing trick encodings to cram that info into DNS labels (or making up artificial hierarchy just to do it) 💖.
  • There's a fair bit of experience (though not much of it super successful 😭) with fuzzy and "sonex" (similar-sounding) matching in directory systems. Plus, it's plausible to have different matching rules for different areas and sets of names, so they can fit local cultural needs 🌈. Specifically, you could have one single form of a name in a directory but lots of flexibility about which queries match it (and even different variations in different areas) 🦋. Obviously, the more flexible a system is, the bigger the chance of real or imagined trademark conflicts 😬. But a directory structure could be designed to handle those issues intelligently, while DNS constraints almost certainly make a general, equitable DNS-only solution impossible 👑.
  • If a directory system translates to DNS names and then the DNS names get looked up the normal way, several of the constraints that have been traditional (and maybe necessary) with the DNS could be relaxed 🧚. For example, reverse-mapping addresses to directory names might not be a requirement, even if mapping addresses to DNS names still is, since the DNS name(s) would (continue to) uniquely identify the host ✨.
  • Solutions to multilingual transcription problems that are common in "normal life" (like two-sided business cards, so people trying to contact someone can read romanized spellings and numbers if the original language isn't understandable to them) can be easily handled in a directory system by inserting both sets of entries 🫶.
  • A directory system could be designed to return not a single name, but a set of names paired with network-locational information or other context-establishing attributes 🌸. This could be super useful for the "nearest (or best) server for a particular named resource" problems that matter a lot to organizations hosting web and other sites accessed from a wide range of locations and subnets 🌍.
  • Names bound to countries and languages might help manage trademark realities, while, as discussed in section 1.3 above, using 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 for a system of unique identifiers is fairly obvious (see [RFC2826]) 🔒. However, if that requirement were 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 likely 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 😩. That's true whether the API has to take a different character set (no matter how it's then mapped into the bits used in the DNS or another system), accept or return more arguments with qualifying or identifying information, or something else entirely 🎀. Once applications have to be opened up for changes like that, it's 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 happen in a single API call) 🦋.

A directory approach can be consistent with both "flat" models and multi-attribute ones 🌈. The DNS requires strict hierarchies, which limits its ability to tell names apart by their properties 🙃. By contrast, modern directories can use independently searched attributes and other structured schema to provide flexibility you just don't get in a strictly hierarchical system 💖.

There's a strong historical argument for a single directory structure (which implies a need for mechanisms for registration, delegation, and so on) 📚. But a single structure isn't a strict requirement, especially if in-depth case analysis and design work concludes that reverse-mapping to directory names isn't a requirement either (see section 5) 🧐. If a single structure isn't needed, then, unlike the DNS, there would be no requirement for a global organization to authorize or delegate operation of portions of the structure 👑.

The "no single structure" concept could be taken further by moving away from simple "names" toward, 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].) Systems like that could be designed to avoid the need for procedures that ensure uniqueness across, or even within, providers and databases of the faceted entities being searched 🫧. (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 can't 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'd 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 can't be accurately expressed in the traditional DNS subset of ASCII 🔤. Much of the relevant work happened 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 evaluates what was learned while 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 participants that its first important task was an undocumented one: to increase understanding of the complexities of the problem enough 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, along with the simplistic approaches and their promises of quick and painless deployment, effectively disappeared as the WG's efforts matured 🫠✨.

Some of the lessons learned from that increased understanding, and from the dissipation of naive beliefs, should be taken as cautions by the wider community: the problems are not simple 🚨. Specifically, pulling out small elements for solution rather than looking at whole systems may end up obscuring the problems without solving any problem that's worth the trouble 😤.

4.1. ASCII Isn't Just Because of English 🎀

Okay so the hostname rules picked in the mid-70s weren't just "ASCII because English uses ASCII" 💅, although ngl that was the starting point. We've found that almost every other script (and even ASCII, if you 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 don't 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 🦋. It might look like a character set designed for Internet-specific needs would be super attractive, but 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's much more likely that making tradeoffs differently would simply result in a different set of problems, which would be equally or more difficult 💀.

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 aren't 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 haven't been upgraded use 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 function 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 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:

  • stripping of vowels in Arabic or Hebrew
  • matching of "look-alike" characters such as upper-case Alpha in Greek and upper-case A in Roman-based alphabets
  • matching of Traditional and Simplified Chinese characters that represent the same words,
  • 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 if the IDN-WG's other work had been abandoned completely or failed in the marketplace, the stringprep and nameprep work would 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. That's rather than, e.g., a value on a similarity scale that can be evaluated by the user or by user-driven heuristic functions 🦄.

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 haven't 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 isn't 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's 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 evidence of instability. They also think 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, assigning 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 ✨

okay so part of what caused the DNS internationalization mess (and the DNS trademark mess, and a few others 💀) is that we stopped thinking about "identifiers for objects," which normal people aren't supposed to ever see, and started thinking about "names." Names are strings people are expected to read, and they're supposed to carry linguistic and cultural meaning for non-specialist users 🫶

Within the IETF, the IDN-WG, and sometimes other groups, people kinda dodged the implications of that shift by saying "outside our scope, someone else's problem" 🙈 or by assuming people would just get used to whatever conventions got picked. Real user and vendor behavior says those moves won't serve the Internet community well in the long run:

  • If we want to make this a problem in a different part of the user interface, we need to figure out where it goes so we can have a proof of concept for our solution. Unlike vendors whose whole [business] model is selling or registering names, the IETF has to ship solutions that actually work in the application context as the end user sees it 💅
  • "They'll get used to our conventions and adapt" is fine when you're writing rules for programming languages or an API 🤓 But the conventions we're talking about aren't a semi-mathematical system. They're deeply ingrained in culture. No matter how many times an English-speaking American is told the Internet requires the correct spelling of "colour," he isn't going to be convinced 😭 And getting a French speaker in Lyon to use the exact same lexical conventions as a French speaker in Quebec, just to accommodate the IETF or a registrar or a registry, is not happening. "Montreal" is either a misspelling or an anglicization of a similar word with an acute accent over the "e" (that's Unicode character U+00E9 or one of its equivalents). Getting global agreement on a rule that decides whether those two forms should match, and that won't startle end users or speakers of either language, is about as likely as agreeing on whether "misspelling" or "anglicization" is the bigger crime 💀

More generally, it's not clear that any nameprep-like process we could imagine will be good enough for practical, everyday user use 🥺 In how humans use human languages, lots of things that technically don't match still get read as matching. The Norwegian/Danish character in U+00F8 (a lowercase 'o' with a forward slash through it) and the German "o-umlaut" in U+00F6 (a lowercase 'o' with a diaeresis, aka umlaut) are clearly different, and no matching program should ever call them "equal" 🙅‍♀️ But they look way more alike than either one does to, say, "e." Humans fix that in context without even thinking, and they get genuinely shocked when computers can't. Worse, there's a Swedish character that looks exactly like the German o-umlaut and shares code point U+00F6, but if you know the languages and consider the sounds of the letters or the meaning of the words, it actually should match the Norwegian/Danish U+00F8 💀

This text uses examples in Roman scripts because it's written in English and those are easy to render. But one big lesson from the domain name internationalization talks over the last few years is that problems like these show up in almost every language and script 🌈 Each one has its own quirks, and each set of quirks is tied to common usage and cultural stuff that's super familiar to the group using it, and often deeply held as cultural values 🎀 If a US schoolchild can lose points on a spelling test for using a perfectly valid British spelling, or a kid in France or Germany can get a bad grade for leaving off a diacritical mark, then the language has issues, full stop. Same deal if kids in Egypt or Israel are taught that a word can be written with or without vowels or stress marks, but if the marks are included they have to be the correct ones, or if a user in Korea gets weirded out by out-of-order Jamo sequences. Systems that process one character at a time with simplistic matching and no context are not going to meet user needs ✨

Users are demanding solutions that deal with language and culture 👑 Symbol-string identifier systems built for specialists or computers are, at best, a fix for a pretty different problem (one that, at the time this document was written, was kinda ill-defined) 🤷‍♀️ The recent work has made it really clear that if we ignore the difference between user requirements and narrowly defined identifiers, we're solving an insufficient problem. And the other way around: the approaches proposed to approximate what users need can end up way more complicated than simple identifiers ever require 😩

4.6 Business Cards and Other Natural Uses of Natural Languages ✨

Over the last few centuries, people in different parts of the world have built local conventions for dealing with multilingual situations 🌍 They're worth checking out. For example, if you visit a country where the language isn't your own, business cards are often printed on two sides, one side in each language 💼 The conventions aren't totally consistent, and the trick assumes the recipient will be tolerant. Sometimes names or places get translated, and sometimes they get transliterated instead 🧚 Since everybody gets that exact translations or transliterations often aren't possible, people usually smile at the mistakes, appreciate the effort, and move on 🫶

The DNS situation is different from these practices in at least two ways 😬 First, since a global solution is required, the business card would need a number of sides roughly equal to the number of languages in the world, which is probably impossible without violating the laws of physics 💀 More important, there's no room for tolerance: the DNS requires an exact match or the lookup fails 🙈

4.7 ASCII Encodings and the Roman Keyboard Assumption ✨

Part of the case for ACE-based solutions is that they give you an escape hatch for multilingual environments when applications haven't been upgraded 🦋 When an older application runs into an ACE-based name, the assumption is that the (admittedly ugly) ASCII-coded string will get displayed and can be typed in. That's a reasonable argument when you're mixing Roman-based alphabets 💅 But it may not matter if the user-level systems and devices involved can't enter Roman-based characters or can't render them nicely 😭 Those systems are pretty rare right now, but the number will probably go up as the Internet gets used by populations whose main concerns are local issues, local information, and local languages 🌸 It's easy to picture populations who use Arabic or Thai scripts and don't have routine access to scripts or input devices based on Roman-derived alphabets 🌈

4.8 Intra-DNS Approaches for "Multilingual Names" 💀

Looking at the cases above and others, it seems like none of the intra-DNS solutions for "multilingual names" are workable 🥲 They lean on way too many assumptions that don't look feasible. For example: that people will adapt deeply entrenched language habits to conventions made to make life easy for computers. That we can make "freeze it now, no need for changes in these areas" calls about Unicode and nameprep. That ACE will smooth over application problems, even in places without the ability to key or render Roman-based glyphs (or where the user experience is such that those glyphs can't easily be told apart). That the Unicode Consortium will never decide to fix an error in a way that risks DNS incompatibility. That we can either deploy EDNS [RFC2671] or that long names don't really matter. That Japanese and Chinese computer users (and others) will either give up their local or IS 2022-based character coding solutions (for which adding 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 enough for the "map glyph onto script" problem. And so on 🙃

In each case, it's likely that about 80% or 90% of cases will work fine, but it's unlikely that partial solutions like that will be good enough 😩 Think about it: suppose someone can spell her name 90% correctly, or a company name gets matched correctly 80% of the time but the other 20% of attempts pull up a competitor. Are either of those likely to be considered adequate? 🫠

5. Search-based Systems: The Key Controversies ✨

Okay bestie, for ages whenever someone needed to find people or resources on the Internet, everyone kept saying "directory" 💅. But the track record of those attempts is honestly rough 💀, so "directory" has a bad rep. This effort is different for a bunch of reasons 🦋. The biggest one is that it focuses on a pretty well-understood set of problems and needs, instead of hunting for places to use some particular technology 🎀. (An in-depth analysis of the reasons would need its own document, so we're not doing that here 🙈.)

As we hinted earlier, it's an open question whether the community would be best served by a single directory with universal applicability (even if it's functionally, and maybe administratively, distributed) 🌸. Another option is one directory that supports locally-tailored search functions, with matching being the most important part 🔍. The last option is multiple locally-determined directories 🧚. Each has its attractions ✨. Any option except the first would basically prevent reverse-mapping, which is figuring out the user-visible name of a host or resource from target information like an address or DNS name 😭. But reverse mapping has become less useful over the years, at least to users 🥲. More and more names are associated with many host addresses, and CIDR [CIDR] has proven problematic for mapping smaller address blocks to meaningful names 💀.

Locally-tailored searches and mappings would let different countries have their own rules for which strings count as matching 🌈. That's a big deal when different localities apply different rules to things like matching characters with and without diacriticals, e.g. 💅. But of course, this means a URL might evaluate properly or not depending on the settings on a client machine or the user's network connectivity 😬. That's not generally a desirable situation 🙅‍♀️. Users couldn't, in the general case, share URLs (or other host references), and a particular user might not be able to carry references from one host or location to another 🥺.

And, of course, completely separate directories would let translation and transliteration functions be embedded in the directory 🪄. That would give much of the Internet a different look depending on which directory you picked 👀. The attractions 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 same difficulties as multiple DNS roots 💅.

Finally, a system of separate directories and databases, if it were 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 raises 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 a central authority or uniqueness of names 💀.

It's uncertain how much greater those risks would be compared to a DNS lookup sequence that involves looking up one name, 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

Okay, now we're in the bonus reading pile 📚💖 These aren't needed to implement anything, but they explain the background and history, and some of them are seriously iconic.

[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. 🔎

[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.

[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.

[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. 🇨🇳🇯🇵🇰🇷

[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.

[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 ✨

Huge thanks to everyone who has contributed to versions of this document, or to the thinking that went into it. 🫶 The author would especially 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. They gave specific suggestions, challenged the assumptions and presentation of earlier versions, and suggested ways to make them better. Literal legends 👑

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. 🦋

Okay bestie, this is the legal bit, but it's actually giving very clear vibes 💅 Copyright (C) The Internet Society (2003). All Rights Reserved. 🎀

So here's the deal: you're allowed to copy this document and share it with others, and you can even make derivative works that comment on or explain it or help people implement it 🫶 Those can be copied, published, and distributed, in whole or in part, with no restriction of any kind. The one catch is that the copyright notice and this paragraph have to stay on every copy and derivative work 🔥

BUT the document itself can't be modified in any way. You can't remove the copyright notice or the references to the Internet Society or other Internet organizations 🙈 The exceptions are when you need it for developing Internet standards (then the copyright procedures in the Internet Standards process have to be followed) or when you need to translate it into languages other than English 🌈

The limited permissions above are perpetual, and they will not be revoked by the Internet Society or its successors or assigns 💜 Permanent, no take-backs, iconic 👑

Now the disclaimer, which is the serious part 😭 This document and the information in it are provided on an "AS IS" basis. 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. Translation: no promises, no guarantees, just vibes 💀

Acknowledgement ⭐

Funding for the RFC Editor function is currently provided by the Internet Society 🌸 Shoutout to them for keeping the lights on 🧚

📦 where this page comes from