ADNS Architecture

Open Issues

• Decide on interfaces provided to TCL interpreter and back to client(Everyone, after the first few things)
• Hack the client library to call out to a TCL interpreter
• Are we ever going to hack the server to do TCL interpretation as well? (This is an eventual goal, but do we want to do it for this project?)

Architecture Decisions

Language: Secure TCL

We've chosen to use Secure TCL for ease-of-use and ease of embedding over languages which may provide more safety (such as Java). Secure TCL appears to offer a more secure alternative than other scripting languages such as SafePerl. We believe that, if we choose the correct interfaces, replacing one language with another in the future will prove relatively easy.

TCL Master/Slave relationship details:
A.

1. Receive reply
2. Decompress into buffer
3. Create Tcl interpreter
4. Set interpreter to Safe mode and set up interfaces.
5. Run interpreter on buffer.
6. Tear down interpreter

Issues include the aforementioned timeout problem and being able to 
transfer bytecode.  I have a feeling that that will involve some clever 
Tcl hacking and will not be portable to new tcl versions.  Any ideas?  If 
speed isn't of the essence it might be better to just plug in a good 
compression algorithm.  I'll look into it.

Response Length

Most DNS servers are optimized for transfers smaller than 512 bytes, since those responses can be handled by a single UDP response packet. Therefore, it behooves us to select a moderately compressed representation for our TCL programs. Fortunately, the DNS architecture can cope with extended-length responses, albeit with reduced performance. For an example of how this is used, see BIND's handling of TXT records, and the define ALLOW_LONG_TXT_RDATA

Unfortunately, there exist some bugs in the client response code handling. If you want to see a cool example of this, try doing an nslookup on one of our entries:

   nslookup
   server torrey.cs.utah.edu
   set querytype=txt
   foo.ourexample.com

Program Representation

Since these programs must also be representable in a format which BIND can parse in its files without great server modifications, we will use one (or both) of the methods below to represent the Active DNS Packets (henceforth called namelets).

• gzip'd TCL code followed by uuencoding (base-64 representation) (allows comments, etc., shrinks to about 75%)
• Strip out all unnecessary whitespace and simply leave as TCL (no comments, variable shrinkage)

For the first stage of our project, we will simply send raw TCL code across the wire. We will leave a hook in the client and the server to compress_namelet() and decompress_namelet() to handle any on-the-wire representation changes we choose to implement. This will let us optimize space later in the game while still maintaining ease of implmentation and debugging. Similar hooks can be imagined in the future for encryption, signing, etc., etc.

Insertion into DNS

For inserting our code into the DNS, we will take another two-phase approach.

• Phase 1: Put Namelets in a "TXT" record, and present a modified resolver library which preferentially fetches these TXT records, passes them to to the TCL interpreter, and returns the results. This will require the least modification of the nameserver (i.e. none).
• Phase 2: Create a new "Active" RR which the client can query offline, to prevent collisions with any actual TXT records.