[e2e] DNS: Directory or Rendevous?

[Micah Beck]

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...

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.

>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.

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.

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.

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?

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.  

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.

Micah Beck
Associate Professor, Computer Science
University of Tennessee

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.postel.org/pipermail/end2end-interest/attachments/20040417/d496ce82/attachment-0001.html