David G. Andersen
The Domain Name System (DNS) is designed to translate human-understandable names, such as ``www.cs.utah.edu'', into routable IP addresses, such as ``220.127.116.11''. While the hierarchical DNS has survived the massive growth of the Internet quite nicely, it is in a position to be more useful to the task of service location than it serves by simply providing static answers to queries. To enhance the functionality of the DNS system, we propose extending it to support the transmission of active code as queries and replies. This code would take the place of current workarounds for service location (such as round-robin DNS for load balancing, special front-ends for closest mirror routing, etc) and would provide an extensible framework for future enhancements.
While many of the examples we propose herein could be handled by modifications to the client or the server, we believe that Active DNS is a better, and more general, framework which would serve the Internet more effectively in the long term.
We want to enhance a DNS server to allow the transmission and reception of a new class of requests/replies which contain code to be executed, instead of simply data to be transmitted. If possible, we would like to have this code be in the form of Java bytecode, but we need to look in to packet length considerations before concretely specifying this (namely, how much data can we send in a DNS request? Can it be UDP? TCP?). The first focus of our research will be examining these issues, and deciding upon a language.
This code would be allowed to do things like communicate with other servers (pings, load balancing queries, etc.) or specify more interesting policies for DNS expiration, cache filling, etc. The second thing we will examine is the set of operations which Active DNS code will need available to provide a sufficiently useful infrastructure.
Once we've come up with answers to these questions, henceforth referred to as ``found a clue,'' we'll implement our DNS extensions. The most likely plan is to implement them as modifications to a current version of BIND 8 from the ISC, but if other (simpler) servers are availalbe, we may switch that focus.
DNS is an established, and evolving, system. The major references for DNS exist in the Internet RFCs (request for comments). We provide a list of the relevant RFCs here; the originals can be found easily in the directory / calfeld/rfc/. The Internet Software Consortium (ISC) is the primary maintainer of the reference DNS software, but many other companies have their own implementations.
Amin Vahdat, as a part of the WebOS research, published ``Active Names: Flexible Location and Transport of Wide-Area Resources'' (http://www.cs.duke.edu/ vahdat). Active Names extends beyond name resolution to furnishing the client with a socket providing the connection to the server. This approach, while more flexible than active DNS, also requires more modification of clients. Also, his approach effectively supplants the traditional DNS system, where Active DNS is built as an extension of DNS, and will be completely backwards compatible. (it will, right?)
RFC1034 - Domain Names - Concepts and Facilities (an intro to DNS) RFC1035 - Domain Names - Implementation and Specification RFC2065 - Domain Name System Security Extensions RFC2308 - Negative Caching of DNS Queries (DNS NCACHE) Development of the Domain Name System (Sigcomm 1998) http://www.isc.org/bind.html - the creators and maintainers of BIND, the most commonly deployed nameserver.
Active DNS would allow clients and servers to specify their own encryption and authentication routines. This would allow secure transactions to take place with the least effort necessary. Dave's comment: What about standards? :) See also ``secure DNS''.
An interesting application that may be possible is the flexible division of IP addresses. CIDR (RFC 1518, RFC 1519) is the current popular policy but with active DNS more flexible and site specific methods could be easily dispatched. Dave's comment: I think we need to expand on this, I'm not really clear what you mean.
Clients could configure servers on the fly to reflect future requests. For example, a client that knows that it will have high levels of repeat requests and very few invalid requests can instruct the server to modify it's caching policy to aggressively cache positive replies and not cache negative replies.
With the possibility of inserting code into specific locations of the server a client could send packets with the purpose of gathering statistics on the server. Alternately an active packet could be sent that gathers statistics and acts (server configuration, request redirection, etc.) based on that information.
Even today a large number of DNS servers have ``non optimal'' settings. The most common error is TTLs that are far shorter than they need to be. An active request could wander around the servers, looking for that and other problems and either reconfigure on the fly or alert the proper manager. This could be done currently by having a program on a host send a series of queries to different DNS servers. With active DNS, however, the calculation is moved closer to the information and network traffic is vastly reduced.
Dave's note: Also, see the regular scanning Bill Manning does for lame delegations, etc..
The flexibility of Active DNS would allow clients to use knowledge of their behavior to instruct the local serve on what to cache (priming). Another cache related example would be TTLs that dynamically change with different request and cache patterns.
Dave's note: Need a reason the clients couldn't do it themselves. :-) I would suggest issues of asynchrony could be useful here, or of having the server do things requiring more data bandwidth than the client has.
A possible application that could be explored is the use of Active DNS to decrease the distance a request travels ``up-tree''.
Many of the above examples have referred to client knowledge being used to improve performance by modifying server behavior. The opposite is also of use. A server that is being bombarded by requests could reconfigure clients to direct future requests to a different server. More elaborate instructions could be used to make server down time transparent by automatically moving requests to another server at a schedule time.
There are a lot of heinous security implications in something like this. We're going to punt on them by now, and handwave about the need for a secure infrastructure with strong authorization of principals.
Active DNS: Resolving the Future
This document was generated using the LaTeX2HTML translator Version 95.1 (Fri Jan 20 1995) Copyright © 1993, 1994, Nikos Drakos, Computer Based Learning Unit, University of Leeds.
The command line arguments were:
latex2html -split 0 prop.tex.
The translation was initiated by David G Andersen on Sat Feb 20 13:37:11 MST 1999