Role of the Domain Name System (DNS)
RFC 3467

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 05

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