<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 6.00.2800.1400" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT face=Arial size=2>In order to discuss the design of the DNS, I have
to state my understanding of its original (or at least early) design
and the requirements that it addressed. Since I was not a part of the
Internet community then, and have not made a careful study, I may make some
misstatements, for which I apologize in advance. However, I am trying to
make a somewhat general point, so I ask everyone to please be a little
forgiving about the details, and not jump on any misstatements too
vigorously unless they are so severe as to render my overall point invalid.
Thank you,and here goes...</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>The early view of the DNS was as a database holding
records that map names to addresses. Each name-to-address mapping was
expected to be fairly static, so it was expected that a distributed
implementation in which hierarchical caching and time-to-live would usually give
a sufficiently consistent result. While the return of invalid DNS records
was fatal to many applications, inconsistency was not, so this model met the
needs of the application community of the time.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>From this historical point of view, using the DNS
in such a manner that it invalidated the assumptions of some applications in the
original community is a misuse, because it can lead to those applications
breaking. However, to the extent that there were widely held assumptions
in the application community that were not part of the DNS specification,
this has leds to some disagreements.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>Over time, the implementation of DNS has been
generalized, and the model has become more complex. Things like rotary
entries correspond to a mapping from a name to a set of addresses, and the
possible behaviors of a "lookup" multiply. Entries have become more
dynamic, and so the difference in effect between different caching policies has
increased. Some people even suggest replacing heirarchical caching with
more explicit and flexible mechanisms for controlling the placement of
mapping information.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>We could say that the requirements of applications
using the DNS have expanded, and the original abstraction is no longer
expressive enough to allow some applications to make use of the underlying
name-to-address mapping mechanism in the way they want. The model could
be adapted, but then the question is: since there are various new and
different ways that applications want to use the DNS, which adaption should be
chosen? To the extent that the different choices are mutually exclusive,
this results in a tussle.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>However, what if rather than building in some
particular new way of describing the structure of the DNS, we were instead to
generalize it, exposing the underlying primitive name-to-address mapping
mechanism, and allowing different resolution, caching and coherence mechanisms
to be built on top of it. In other words, what if the common scalable
network resource were implemented in a primitive common service at a lower
layer, with various higher level strategies built on top? What is the
common service for various approaches to the DNS?</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>One can view the DNS as being built on top of
lower level rendevous messaging service. Registering a name-to-address
mapping at a particular DNS server is equivalent to sending a messaging to a
rendevous with that name. The message being sent informs the receiver
that the name resolved to a particular address for a particular duration of
time. The message itself will exist at the rendevous for a limited
amount of time, specified by the sender. </FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>The idea of a global table that is implemented
using this mechanism, and is cached hierarchically with certain loose
expectations of consistency is historical, and applies only when used with
particular class of caching algorithm. Some newer
ways that people want to use the DNS are more naturally expressed in terms
of a more primitive, less structured rendevous system for distributing mappings
and metadata about mappings. The current DNS service would simply become
one set of conventions for this rendevous system, imposed by client
software whose purposes it serves. The underlying storage and
synchronization services would be available for more general use.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>Micah Beck</FONT></DIV>
<DIV><FONT face=Arial size=2>Associate Professor, Computer Science</FONT></DIV>
<DIV><FONT face=Arial size=2>University of Tennessee</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV></BODY></HTML>