summaryrefslogtreecommitdiff
path: root/contrib/bind9/doc/rfc/rfc2826.txt
diff options
context:
space:
mode:
Diffstat (limited to 'contrib/bind9/doc/rfc/rfc2826.txt')
-rw-r--r--contrib/bind9/doc/rfc/rfc2826.txt339
1 files changed, 0 insertions, 339 deletions
diff --git a/contrib/bind9/doc/rfc/rfc2826.txt b/contrib/bind9/doc/rfc/rfc2826.txt
deleted file mode 100644
index b4d886968fc88..0000000000000
--- a/contrib/bind9/doc/rfc/rfc2826.txt
+++ /dev/null
@@ -1,339 +0,0 @@
-
-
-
-
-
-
-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]
-