Network2/Experiments/tinydns

Workable DynDNS

There seems to be no widely-adopted standard API for (remotely) modifying DNS zone files. For example, the standardized DNS UPDATE protocols defined by RFCs 2136 and 3007 seem to be sparsely implemented at best. Other approaches, like draft-jennings-app-dns-update-02 have not been standardized. Finally, there are open problems with truth maintenance as described in other unstandardized work draft-sekar-dns-ul-01.

So what are our real options?

The simplest thing that could possibly work would be to SSH or SSL to the DNS server we want to update. A successful SSH or SSL authentication binds together a username or client CN (which identifies the subdomain to update) and an IP address which we can use to generate the new RRset for that subdomain.

This will work well so long as we can commit up-front to an address and port number for our "olpcdyndns" server listen on. Unfortunately, it seems likely that large-scale providers of this olpcdyndns service will want to be able to provide service to multiple independent domains from a single machine, e.g. via vhosting.

To support vhosting, we need a way to communicate address/port information from the server to the client (for availability) and from the client back to the server (for integrity).

The server-to-client communication may be handled without undue difficulty by using DNS-SD to inform clients what port to connect to.

In the simplest case, suppose that we want to set up DNS-SD for a fixed instance named "primary" at olpcdyndns host <foo>.

In that case, we can use a single SRV record with priority 0, weight 0, zone

primary._olpcdyndns1._tcp.<foo>

and whatever hostname and port we like to point to our real olpcdyndns server.

On the client, we can extract the specified host and port with

SRV=$(dig +short -t srv primary._olpcdyndns1._tcp.<foo>)
PORT=$(echo "$SRV" | cut -d' ' -f3)
HOST=$(echo "$SRV" | cut -d' ' -f4-)

Auxiliary information, if we had any, could be acquired via

TXT=$(dig +short -t txt primary._olpcdyndns1._tcp.<foo>)

If you want to get fancy, you could also loop over _olpcdyndns services with something like:

for PTR in $(dig +short -t ptr _olpcdyndns1._tcp.<foo>); do
  SRV=$(dig +short -t srv "$SRV")
  ...
done

Next, what should we run on this carefully communicated host+port combination?

Depending on our preference, we can either use

 ssh -p $PORT $HOST /usr/bin/olpc-dyndns-1-ssh-update

or we can use SSL with SNI like so: (with openssl >= 0.9.8j)

 openssl s_client -connect $HOST:$PORT -servername <foo> -cert <my_cert> -key <my_key>

to trigger /usr/bin/olpc-dyndns-1-ssl-update through something like stunnel or ucspi-ssl's sslserver.

The mythical olpc-dyndns-1-ssh-update can read SSH_CONNECTION to find out the connecting IP; the mythical olpc-dyndns-1-ssl-update can read REMOTE_HOST and SSL_CLIENT_DN (with stunnel) or the sslserver equivalents.

Setting

 LogLevel VERBOSE

in /etc/ssh/sshd_config will cause SSH to log key fingerprints as well as accounts in case you want to manage everything from a single account. There doesn't seem to be any way (at present) to find out the key fingerprint of an active SSH session except by log-munging. (grr!).

...

Going with openssl:

openssl genrsa -out ca.key 1024
openssl req -new -x509 -nodes -sha1 -days 9999 -key ca.key -out ca.key

openssl genrsa -out client.key 1024
openssl req -new -x509 -nodes -sha1 -days 9999 -key client.key -out client.pem

openssl x509 -in client.pem -out client.pem -CA ca.pem -CAkey ca.key -days 9999 -CAcreateserial
openssl verify -CAfile ca.pem client.cert