An important feature of DNS is that it is heirarchical. This means that you don't have to know in advance which name server to ask for an answer. For an example, let's see what happens when a user at soda.berkeley.edu tries to look up the machine ltt2.lcs.mit.edu.
The first thing that happens is that the program doing the lookup will contact the system's default name server. Since soda runs its own name server, it will use that service. Since the soda name server immediately recognizes the name as one which is not in its local database, it tries to connect to a name server which does have the entry in its local database. It does this by moving up the heirarchy until it has found the proper name server. The levels of the heirarchy are separated by .'s (periods). So ltt2.lcs.mit.edu is the machine ltt2, in the lcs heirarchy, which is in the mit heirarchy, which is in the edu top level domain. By querying a standard server which knows all the name servers for the edu top level domain, it can find out the the server bitsy.mit.edu is the right server to ask about addresses at MIT. The program then queries bitsy about the address. Bitsy does not have the address ltt2.lcs.mit.edu in its local database, but it informs the program that mintaka.lcs.mit.edu knows about addresses in the lcs domain. The program finally asks mintaka, which returns the IP address 18.26.0.175.
Another important feature of DNS is that it caches queries and answers. So if another user at soda then tries to look up ltt2.lcs.mit.edu, the soda nameserver will immediately reply with the IP address it just obtained.
In addition, DNS is not limited to just IP addresses. MX (mail exchangers), CNAME (canonical name), ALIAS (name aliases) and NS (name server) records are also widely used. However, you can add records of type TXT for arbitrary text. These are the type of records which the CSTR DNS services use.
We create DNS names of the form {id}.{service}.{nameserver}. The id field contains a RFC 1357 ID for a techinical report. The service field currently can be either url to return a URL to the TR, or formats to return a list of formats in which the TR is available. The nameserver field is currently set to ltt-ns.lcs.mit.edu, which is the name of the server which contains all the records. By looking up these names using DNS, the TXT record returned will contain the answer to your query. For example, looking up the TXT record associated with the name MIT-AILab//AIM-1114.url.ltt-ns.lcs.mit.edu, you will get an answer of the form http://cstr-http.lcs.mit.edu/TR/MIT-AILab:AIM-1114. Replacing the string url with formats will return a list of available formats for the TR instead.
Our service is updated weekly by asking each CSTR server which TRs it has available and recording the address into the url database. Then, for each TR online, it queries the server holding that TR for the formats available. Once this is done, it constructs a DNS name table consisting of the TR name, either url or formats, and then the appropriate response.
Using the DNS service provides two uncontestable benefits. One is speed. Using the demo it will become clear that doing DNS queries for the status of a TR is orders of magnitude faster than querying the server directly. The other is abstraction. It the server which contains a TR moves, or becomes unavailable, it is trivial to modify the DNS table to reflect this information. Lookups via DNS will then automatically return the correct location for the server. However, hard coded lookups of the server will fail. For these reasons, we believe that DNS is a valuable resource for the CSTR project.