DNS
Click on the red underlined text to get to the source
...
The DNS was designed as a replacement for the older "host table"
system. Both were intended to provide names for network ...
... 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
...
... 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 ...
... 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 ...
... namespace (the "Class=IN" DNS) in the light of subsequent development
and experience. In addition, the historical reasons for particular
decisions about the Internet ...
... important. Consequently, the quasi-historical story below is just
one story. There may be (indeed, almost certainly are) other stories
about how the DNS evolved to its present state, but those variants do
not invalidate the inferences and conclusions.
...
... discussions
and meetings were held which drew several ideas and incomplete
proposals together. The DNS was the result of that effort. It
continued to evolve during the design and initial implementation
period, with a number of documents recording the changes (see
...
... electronic mail routing which quickly followed
introduction of the DNS), and
o Creation of a robust, hierarchical, distributed, name lookup ...
... system to accomplish the other goals.
The DNS design also permitted distribution of name administration,
rather than requiring that each host be entered into a single,
...
...
The DNS was designed to identify network resources. Although there
was speculation about including, e.g., personal names and email
addresses ...
... host table.
However, the DNS, as it is actually used, is intimately tied to the
applications and application protocols that utilize it, often at a
...
...
In particular, despite the ability of the protocols and data
structures themselves to accommodate any binary representation, DNS
names as used were historically not even unrestricted ASCII, but a
very restricted subset of it, a subset that derives from the original
...
... example of the deeply hierarchical approach. However, by 1998,
comparison of several efforts to survey the DNS showed a count of SOA
records that approached (and may have passed) the number of distinct
hosts ...
... names onto a smaller number of hosts. While experience up to this
time has shown that the DNS is robust enough -- given contemporary
machines as servers and current bandwidth norms -- to be able to
...
... Similarly, despite some early speculation about entering people's
names and email addresses into the DNS directly (e.g., see
[RFC1034]), electronic mail ...
... addresses in the Internet have preserved
the original, pre-DNS, "user (or mailbox) at location" conceptual
format rather than a flatter or strictly dot-separated one.
...
... hosts. Despite the observation in RFC 1034std13
that the DNS was expected to grow to be proportional to the number of
users (section 2.3), it has never been clear that the DNS was
...
... that the DNS was expected to grow to be proportional to the number of
users (section 2.3), it has never been clear that the DNS was
seriously designed for, or could, scale to the order of magnitude of
number of users (or, more recently, products or document objects),
...
...
Just as was the case for the host table before it, the DNS provided
critical uniqueness for names, and universal accessibility to them,
...
... system was being stretched to, or beyond, its practical limits.
The original design effort that led to the DNS included examination
of the directory technologies available at the time. The design
group ...
... of 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
...
... context of the two- (or more) level
mechanism contemplated by the rest of this document or, even more
radically, as a path toward a DNS replacement.
...
... desire to make domain names out of easily-remembered product names,
has led to a flattening of the DNS, with many people now perceiving
that second-level names under COM (or in some countries, second- or
third-level names under the relevant ccTLD) are all that is
...
... network, with a user who asks for the
information by name getting the topologically-closest copy. This is
not possible with simple, as-designed, use of the DNS: DNS names
identify target ...
... information by name getting the topologically-closest copy. This is
not possible with simple, as-designed, use of the DNS: DNS names
identify target resources or, in the case of email ...
... to the source/user). Several technologies (and, in some cases,
corresponding business models) have arisen to work around these
problems, including intercepting and altering DNS requests so as to
point to other locations.
...
...
Approaches that involve interception of DNS queries and rewriting of
DNS names (or otherwise altering the resolution process based on the
...
... interception of DNS queries and rewriting of
DNS names (or otherwise altering the resolution process based on the
topological location of the user) seem, however, to risk disrupting
end-to-end ...
... applications that need to identify "the same host" often run into
problems if DNS names or other references are changed in the network
without participation of the applications that are trying to invoke
...
... deployment of high-quality replacements.
The DNS is both an illustration of, and an exception to, parts of
this pessimistic interpretation. It was a second-generation
development, with the host ...
... Signs of DNS Overloading ...
... Parts of the historical discussion above identify areas in which the
DNS has become overloaded (semantically if not in the mechanical
ability to resolve names). Despite this overloading, it appears that
...
... overloaded (semantically if not in the mechanical
ability to resolve names). Despite this overloading, it appears that
DNS performance and reliability are still within an acceptable range ...
... proposals and mechanisms to better respond to overloading and scaling
issues have all focused on patching or working around limitations
that develop when the DNS is utilized for out-of-design functions,
rather than on dramatic rethinking of either DNS design or those
...
... that develop when the DNS is utilized for out-of-design functions,
rather than on dramatic rethinking of either DNS design or those
uses. The number of these issues that have arisen at much the same
time may argue for just that type of rethinking, and not just for
...
... 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
...
... multiple
addresses on a physical interface and some protocols have been
extended to include DNS names for determining context, the DNS
...
... extended to include DNS names for determining context, the DNS
does not deal especially well with many names associated with a
given host ...
... 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
...
... 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
...
... "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
...
...
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 ...
... the characteristics of common content negotiation approaches are
workarounds for the non-optimal use of the DNS in web URLs.
...
... 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
...
... 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
...
... worst types of confusion (and opportunities for fraud).
o The historical DNS, and applications that make assumptions about
how it works, impose significant risk (or forces technical kludges
...
...
o In order to provide proper functionality to the Internet, the DNS
must have a single unique root (the IAB ...
... search not only
an index entry (labels or fully-qualified names in the DNS case),
but their values or targets (DNS data ...
... DNS case),
but their values or targets (DNS data). One might, for example,
want to locate all of the host (and virtual host ...
... 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 ...
...
o 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 ...
... 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
...
...
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
...
... 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
...
... Searching, Directories, and the DNS ...
...
The constraints of the DNS and the discussion above suggest the
introduction of an intermediate protocol mechanism ...
... lookup, not
unlike several of the proposals for internationalized names in the
DNS (see section 4), but all operations but the final one would
involve searching other systems, rather than looking up identifiers
...
... involve searching other systems, rather than looking up identifiers
in the DNS itself. As explained below, this would permit relaxation
of several constraints, leading to a more capable and comprehensive
...
... Ultimately, many of the issues with domain names arise as the result
of efforts to use the DNS as a directory. While, at the time this
document was written, sufficient pressure or demand had not occurred
to justify a change, it was already quite clear that, as a directory
...
... document was written, sufficient pressure or demand had not occurred
to justify a change, it was already quite clear that, as a directory
system, the DNS is a good deal less than ideal. This document
suggests that there actually is a requirement for a directory system,
...
... and that the right solution to a searchable system requirement is a
searchable system, not a series of DNS patches, kludges, or
workarounds.
...
... having to utilize trick encodings to incorporate that information
in DNS labels (or creating artificial hierarchy for doing so).
o There is considerable experience (albeit not much of it very
...
... conflicts. But the opportunity would exist to design a directory
structure that dealt with those issues in an intelligent way,
while DNS constraints almost certainly make a general and
equitable DNS ...
... DNS constraints almost certainly make a general and
equitable DNS-only solution impossible.
o If a directory system is used to translate to DNS names ...
... DNS-only solution impossible.
o If a directory system is used to translate to DNS names, and then
DNS names are looked up in the normal fashion, it may be possible
...
... o If a directory system is used to translate to DNS names, and then
DNS names are looked up in the normal fashion, it may be possible
to relax several of the constraints that have been traditional
...
... to relax several of the constraints that have been traditional
(and perhaps necessary) with the DNS. For example, reverse-
mapping of addresses to directory names may not be a requirement ...
... requirement
even if mapping of addresses to DNS names continues to be, since
the DNS name(s) would (continue to) uniquely identify the host ...
... addresses to DNS names continues to be, since
the DNS name(s) would (continue to) uniquely identify the host.
...
... languages might help to manage
trademark realities, while, as discussed in section 1.3 above, use
of 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 to have a
system of unique identifiers ...
... requirement were to be 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 be likely to vanish.
...
... Almost any internationalization proposal for names that are in, or
map into, the DNS will require changing DNS resolver API calls
...
... 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
...
... character set (no matter how it
is then mapped into the bits used in the DNS or another system), to
accept or return more arguments with qualifying or identifying
information, or otherwise. Once applications must be opened to make
...
... such changes, it is a relatively small matter to switch from calling
into the DNS to calling a directory service and then the DNS (in many
...
... into the DNS to calling a directory service and then the DNS (in many
situations, both actions could be accomplished in a single API call).
...
...
A directory approach can be consistent both with "flat" models and
multi-attribute ones. The DNS requires strict hierarchies, limiting
its ability to differentiate among names by their properties. By
contrast, modern directories can utilize independently-searched
...
... not a requirement (see section 5). If a single structure is not
needed, then, unlike the DNS, there would be no requirement for a
global organization to authorize or delegate operation of portions of
...
...
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 ...
... considerations of internationalizing the DNS or, more specifically,
providing access to the functions of the DNS from languages and
naming systems that cannot be accurately expressed in the traditional
...
... languages and
naming systems that cannot be accurately expressed in the traditional
DNS subset of ASCII. Much of the relevant work was done in the
IETF ...
... discussions
in other forums. This section contains an evaluation of what was
learned as an "internationalized DNS" or "multilingual DNS" was
explored and suggests future steps based on that evaluation.
...
... in other forums. This section contains an evaluation of what was
learned as an "internationalized DNS" or "multilingual DNS" was
explored and suggests future steps based on that evaluation.
...
...
While the DNS can handle arbitrary binary strings without known
internal problems (see [RFC2181]), some restrictions are imposed by
...
... ACE). These encodings
preserve the LDH conventions in the DNS itself. Implementations of
applications that have not been upgraded utilize the encoded forms,
while newer ones can be written to recognize the special codings and
...
... 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
...
... 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
...
... client-side,
canonicalization or "preparation" process before the DNS matching
mechanisms are invoked [STRINGPREP].
...
... 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
...
... 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 eliminates or
rejects spurious character codes, maps some characters onto others,
...
... 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.
...
... 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 ...
... stringprep" and "nameprep" work, but it is not
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 ...
... 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
...
... create issues that cause instability in the implementation and
resolution models for the DNS.
The Unicode ...
... 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 ...
... DNS internationalization problem, as
well as the DNS trademark problem and several others, is that we have
stopped thinking about "identifiers for objects" -- which normal
...
... errors, appreciate the effort, and move on.
The DNS situation differs from these practices in at least two ways.
Since a global solution is required, the business card would need a
number of sides approximating the number of languages ...
... languages in the world,
which is probably impossible without violating laws of physics. More
important, the opportunities for tolerance don't exist: the DNS
requires a exact match or the lookup fails.
...
... Intra-DNS Approaches for "Multilingual Names" ...
...
It appears, from the cases above and others, that none of the intra-
DNS-based solutions for "multilingual names" are workable. They rest
on too many assumptions that do not appear to be feasible -- that
people will adapt deeply-entrenched language ...
... Consortium will never decide to repair an error in a way that creates
a risk of DNS incompatibility; that we can either deploy EDNS
[RFC2671] or that long names are not really important; that Japanese
...
... or resource from target information such as an address or DNS name).
But reverse mapping has become less useful over the years --at least
to users -- as more and more names have been associated with many
...
... uniqueness and precise identities at the right points (which may or
may not be possible), such a system would have many of the
difficulties associated with multiple DNS roots.
Finally, a system of separate directories and databases ...
... Finally, a system of separate directories and databases, if coupled
with removal of the DNS-imposed requirement for unique names, would
largely eliminate the need for a single worldwide authority ...
... 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 central authority ...
... authority or uniqueness of
names. It is uncertain how much greater those risks would be as
compared to a DNS lookup sequence that involved looking up one name,
getting back information, and then doing additional lookups ...
... Any of the editions of Albitz, P. and C. Liu, DNS and BIND, O'Reilly and Associates, 1992, 1997, 1998, 2001. ...
... 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. ...
... 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. ...
... Mealling, M. and R. Daniel, "The Naming Authority Pointer (NAPTR) DNS Resource Record", RFC 2915(-> 3404prop | 3403prop | 3402prop | 3401), September 2000. Mealling, M., "Dynamic Delegation Discovery System (DDDS ...
... Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database", RFC 3403prop, October 2002. ...
... 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 ...
... 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 ...
... stringprep)", RFC 3454prop, 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 ...