340 lines
13 KiB
Plaintext
340 lines
13 KiB
Plaintext
|
||
|
||
|
||
|
||
|
||
|
||
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]
|
||
|