Network2/Experiments/tinydns: Difference between revisions
mNo edit summary |
mNo edit summary |
||
Line 84: | Line 84: | ||
chmod a+x ./hiya |
chmod a+x ./hiya |
||
# with ipv4 on localhost: |
|||
stunnel -p ca.pem -v 2 -A ca.cert -d 3001 -f -P '' -l ./hiya |
stunnel -p ca.pem -v 2 -A ca.cert -d 3001 -f -P '' -l ./hiya |
||
openssl s_client -connect localhost:3001 -cert client.cert -key client.key -CAfile ca.cert |
openssl s_client -connect localhost:3001 -cert client.cert -key client.key -CAfile ca.cert |
||
# openssl s_client doesn't support ipv6; see, e.g. openssl #1365, #1832 |
|||
sudo dnshash attach michael.mstone.info |
|||
stunnel -p ca.pem -v 2 -A ca.cert -d michael.mstone.info:3001 -f -P '' -l ./hiya |
|||
ncat -6 -v --ssl --ssl-key client.key --ssl-verify --ssl-cert client.cert michael.mstone.info 3001 |
Revision as of 03:16, 1 January 2010
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.cert openssl genrsa -out client.key 1024 openssl req -new -nodes -sha1 -days 9999 -key client.key -out client.csr openssl x509 -req -in client.csr -out client.cert -CA ca.cert -CAkey ca.key -days 9999 -CAcreateserial openssl verify -CAfile ca.pem client.cert cat client.cert client.key > client.pem cat > hiya <<EOF #!/bin/bash echo $SSL_CLIENT_DN echo $SSL_CLIENT_I_DN echo $REMOTE_HOST EOF chmod a+x ./hiya # with ipv4 on localhost: stunnel -p ca.pem -v 2 -A ca.cert -d 3001 -f -P -l ./hiya openssl s_client -connect localhost:3001 -cert client.cert -key client.key -CAfile ca.cert
# openssl s_client doesn't support ipv6; see, e.g. openssl #1365, #1832 sudo dnshash attach michael.mstone.info stunnel -p ca.pem -v 2 -A ca.cert -d michael.mstone.info:3001 -f -P -l ./hiya ncat -6 -v --ssl --ssl-key client.key --ssl-verify --ssl-cert client.cert michael.mstone.info 3001