doc: Add RFC documents

1 files changed, 339 insertions, 0 deletions

diff --git a/doc/rfc/rfc2826.txt b/doc/rfc/rfc2826.txt
new file mode 100644
index 0000000..f31054e
--- /dev/null
+++ b/doc/rfc/rfc2826.txt
@@ -0,0 +1,339 @@
+
+
+
+
+
+
+Network Working Group                        Internet Architecture Board
+Request for Comments: 2826                                      May 2000
+Category: Informational
+
+
+              IAB Technical Comment on the Unique DNS Root
+
+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 (2000).  All Rights Reserved.
+
+Summary
+
+   To remain a global network, the Internet requires the existence of a
+   globally unique public name space.  The DNS name space is a
+   hierarchical name space derived from a single, globally unique root.
+   This is a technical constraint inherent in the design of the DNS.
+   Therefore it is not technically feasible for there to be more than
+   one root in the public DNS.  That one root must be supported by a set
+   of coordinated root servers administered by a unique naming
+   authority.
+
+   Put simply, deploying multiple public DNS roots would raise a very
+   strong possibility that users of different ISPs who click on the same
+   link on a web page could end up at different destinations, against
+   the will of the web page designers.
+
+   This does not preclude private networks from operating their own
+   private name spaces, but if they wish to make use of names uniquely
+   defined for the global Internet, they have to fetch that information
+   from the global DNS naming hierarchy, and in particular from the
+   coordinated root servers of the global DNS naming hierarchy.
+
+1.  Detailed Explanation
+
+   There are several distinct reasons why the DNS requires a single root
+   in order to operate properly.
+
+1.1.  Maintenance of a Common Symbol Set
+
+   Effective communications between two parties requires two essential
+   preconditions:
+
+
+
+IAB                          Informational                      [Page 1]
+
+RFC 2826      IAB Technical Comment on the Unique DNS Root      May 2000
+
+
+   -  The existence of a common symbol set, and
+
+   -  The existence of a common semantic interpretation of these
+      symbols.
+
+   Failure to meet the first condition implies a failure to communicate
+   at all, while failure to meet the second implies that the meaning of
+   the communication is lost.
+
+   In the case of a public communications system this condition of a
+   common symbol set with a common semantic interpretation must be
+   further strengthened to that of a unique symbol set with a unique
+   semantic interpretation.  This condition of uniqueness allows any
+   party to initiate a communication that can be received and understood
+   by any other party.  Such a condition rules out the ability to define
+   a symbol within some bounded context.  In such a case, once the
+   communication moves out of the context of interpretation in which it
+   was defined, the meaning of the symbol becomes lost.
+
+   Within public digital communications networks such as the Internet
+   this requirement for a uniquely defined symbol set with a uniquely
+   defined meaning exists at many levels, commencing with the binary
+   encoding scheme, extending to packet headers and payload formats and
+   the protocol that an application uses to interact.  In each case a
+   variation of the symbol set or a difference of interpretation of the
+   symbols being used within the interaction causes a protocol failure,
+   and the communication fails.  The property of uniqueness allows a
+   symbol to be used unambiguously in any context, allowing the symbol
+   to be passed on, referred to, and reused, while still preserving the
+   meaning of the original use.
+
+   The DNS fulfills an essential role within the Internet protocol
+   environment, allowing network locations to be referred to using a
+   label other than a protocol address.  As with any other such symbol
+   set, DNS names are designed to be globally unique, that is, for any
+   one DNS name at any one time there must be a single set of DNS
+   records uniquely describing protocol addresses, network resources and
+   services associated with that DNS name.  All of the applications
+   deployed on the Internet which use the DNS assume this, and Internet
+   users expect such behavior from DNS names.  Names are then constant
+   symbols, whose interpretation does not specifically require knowledge
+   of the context of any individual party.  A DNS name can be passed
+   from one party to another without altering the semantic intent of the
+   name.
+
+   Since the DNS is hierarchically structured into domains, the
+   uniqueness requirement for DNS names in their entirety implies that
+   each of the names (sub-domains) defined within a domain has a unique
+
+
+
+IAB                          Informational                      [Page 2]
+
+RFC 2826      IAB Technical Comment on the Unique DNS Root      May 2000
+
+
+   meaning (i.e., set of DNS records) within that domain.  This is as
+   true for the root domain as for any other DNS domain.  The
+   requirement for uniqueness within a domain further implies that there
+   be some mechanism to prevent name conflicts within a domain.  In DNS
+   this is accomplished by assigning a single owner or maintainer to
+   every domain, including the root domain, who is responsible for
+   ensuring that each sub-domain of that domain has the proper records
+   associated with it.  This is a technical requirement, not a policy
+   choice.
+
+1.2.  Coordination of Updates
+
+   Both the design and implementations of the DNS protocol are heavily
+   based on the assumption that there is a single owner or maintainer
+   for every domain, and that any set of resources records associated
+   with a domain is modified in a single-copy serializable fashion.
+   That is, even assuming that a single domain could somehow be "shared"
+   by uncooperating parties, there is no means within the DNS protocol
+   by which a user or client could discover, and choose between,
+   conflicting definitions of a DNS name made by different parties.  The
+   client will simply return the first set of resource records that it
+   finds that matches the requested domain, and assume that these are
+   valid.  This protocol is embedded in the operating software of
+   hundreds of millions of computer systems, and is not easily updated
+   to support a shared domain scenario.
+
+   Moreover, even supposing that some other means of resolving
+   conflicting definitions could be provided in the future, it would
+   have to be based on objective rules established in advance.  For
+   example, zone A.B could declare that naming authority Y had been
+   delegated all subdomains of A.B with an odd number of characters, and
+   that naming authority Z had been delegated authority to define
+   subdomains of A.B with an even number of characters.  Thus, a single
+   set of rules would have to be agreed to prevent Y and Z from making
+   conflicting assignments, and with this train of actions a single
+   unique space has been created in any case.  Even this would not allow
+   multiple non-cooperating authorities to assign arbitrary sub-domains
+   within a single domain.
+
+   It seems that a degree of cooperation and agreed technical rules are
+   required in order to guarantee the uniqueness of names.  In the DNS,
+   these rules are established independently for each part of the naming
+   hierarchy, and the root domain is no exception.  Thus, there must be
+   a generally agreed single set of rules for the root.
+
+
+
+
+
+
+
+IAB                          Informational                      [Page 3]
+
+RFC 2826      IAB Technical Comment on the Unique DNS Root      May 2000
+
+
+1.3.  Difficulty of Relocating the Root Zone
+
+   There is one specific technical respect in which the root zone
+   differs from all other DNS zones: the addresses of the name servers
+   for the root zone come primarily from out-of-band information.  This
+   out-of-band information is often poorly maintained and, unlike all
+   other data in the DNS, the out-of-band information has no automatic
+   timeout mechanism.  It is not uncommon for this information to be
+   years out of date at many sites.
+
+   Like any other zone, the root zone contains a set of "name server"
+   resource records listing its servers, but a resolver with no valid
+   addresses for the current set of root servers will never be able to
+   obtain these records.  More insidiously, a resolver that has a mixed
+   set of partially valid and partially stale out-of-band configuration
+   information will not be able to tell which are the "real" root
+   servers if it gets back conflicting answers; thus, it is very
+   difficult to revoke the status of a malicious root server, or even to
+   route around a buggy root server.
+
+   In effect, every full-service resolver in the world "delegates" the
+   root of the public tree to the public root server(s) of its choice.
+
+   As a direct consequence, any change to the list of IP addresses that
+   specify the public root zone is significantly more difficult than
+   changing any other aspect of the DNS delegation chain.   Thus,
+   stability of the system calls for extremely conservative and cautious
+   management of the public root zone: the frequency of updates to the
+   root zone must be kept low, and the servers for the root zone must be
+   closely coordinated.
+
+   These problems can be ameliorated to some extent by the DNS Security
+   Extensions [DNSSEC], but a similar out-of-band configuration problem
+   exists for the cryptographic signature key to the root zone, so the
+   root zone still requires tight coupling and coordinated management
+   even in the presence of DNSSEC.
+
+2.  Conclusion
+
+   The DNS type of unique naming and name-mapping system may not be
+   ideal for a number of purposes for which it was never designed, such
+   a locating information when the user doesn't precisely know the
+   correct names.  As the Internet continues to expand, we would expect
+   directory systems to evolve which can assist the user in dealing with
+   vague or ambiguous references.  To preserve the many important
+   features of the DNS and its multiple record types -- including the
+   Internet's equivalent of telephone number portability -- we would
+   expect the result of directory lookups and identification of the
+
+
+
+IAB                          Informational                      [Page 4]
+
+RFC 2826      IAB Technical Comment on the Unique DNS Root      May 2000
+
+
+   correct names for a particular purpose to be unique DNS names that
+   are then resolved normally, rather than having directory systems
+   "replace" the DNS.
+
+   There is no getting away from the unique root of the public DNS.
+
+3.  Security Considerations
+
+   This memo does not introduce any new security issues, but it does
+   attempt to identify some of the problems inherent in a family of
+   recurring technically naive proposals.
+
+4.  IANA Considerations
+
+   This memo is not intended to create any new issues for IANA.
+
+5.  References
+
+   [DNS-CONCEPTS]        Mockapetris, P., "Domain Names - Concepts and
+                         Facilities", STD 13, RFC 1034, November 1987.
+
+   [DNS-IMPLEMENTATION]  Mockapetris, P., "Domain Names - Implementation
+                         and Specification", STD 13, RFC 1035, November
+                         1987.
+
+   [DNSSEC]              Eastlake, D., "Domain Name System Security
+                         Extensions", RFC 2535, March 1999.
+
+6.  Author's Address
+
+   Internet Architecture Board
+
+   EMail: iab@iab.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+IAB                          Informational                      [Page 5]
+
+RFC 2826      IAB Technical Comment on the Unique DNS Root      May 2000
+
+
+7.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2000).  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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+IAB                          Informational                      [Page 6]
+