I used to have a static IP address on my home ADSL connection, but then I moved to BT Infinity, and they don’t provide that ability. For whatever reason, my Infinity connection resets a few times a week, and it always results in a new IP address.
Since I wanted to be able to connect to a service on my home IP address, I signed up to dyn.com and used their free service for a while, using a CNAME with my hosting provider (Gandi) so that I could use a single common host, in my own domain, and point it to the dynamic IP host and hence, dynamic IP address.
While this works fine, I’ve had a few e-mails from dyn.com where either the update process hasn’t been enough to prevent the ’30 day account closure’ process, or in recent times, a mail saying they’re changing that and you now need to log in on the website once every 30 days to keep your account.
I finally decided that since I run a couple of VPSs, and have good control over DNS via Gandi, I may as well run my own bind9 service and use the dynamic update feature to handle my own dynamic DNS needs. Side note: I think Gandi do support DNS changes through their API, but I couldn’t get it working. Also, I wanted something agnostic of my hosting provider in case I ever move DNS in future (I’m not planning to, since I like Gandi very much).
The basic elements of this are,
- a bind9 service running somewhere, which can host the domain and accept the updates.
- delegation of a subdomain to that bind9 service. Since Gandi runs my top level domain for me, I need to create a subdomain and delegate to it, and then make dynamic updates into that subdomain. I can still use CNAMEs in the top level domain to hide the subdomain if I wish.
- configuration of the bind9 service to accept secure updates.
- a script to do the updates.
In the interests of not re-inventing the wheel, I copied most of the activity from this post. But I’ll summarise it here in case that ever goes away.
Installing / Configuring bind9
You’ll need somewhere to run a DNS (bind9 in my case) service. This can’t be on the machine with the dynamic IP address for obvious reasons. If you already have a DNS service somewhere, you can use that, but for me, I installed it on one of my Debian VPS machines. This is of course trivial with Debian (I don’t use sudo, so you’ll need to be running as root to execute these commands),
apt-get install bind9 bind9-doc
If the machine you’ve installed bind9 onto has a firewall, don’t forget to open ports 53 (both TCP and UDP). You now need to choose and configure your subdomain. You’ll be creating a single zone, and allowing dynamic updates.
The default config for bind9 on Debian is in /etc/bind, and that includes zone files. However, dynamically updated zones need a journal file, and need to be modified by bind. I didn’t even bother trying to put the file into /etc/bind, on the assumption bind won’t have write access, so instead, for dynamic zones, I decided to create them in /var/lib/bind. I avoided /var/cache/bind because the cache directory, in theory, is for transient files that applications can recreate. Since bind can’t recreate the zone file entirely, it’s not appropriate to store it there.
I added this section to /etc/bind/named.conf.local,
// Dynamic zone
zone "home.example.com" {
type master;
file "/var/lib/bind/home.example.com";
update-policy {
// allow host to update themselves with a key having their own name
grant *.home.example.com self home.example.com.;
};
};
This sets up the basic entry for the master zone on this DNS server.
Create Keys
So I’ll be honest, I’m following this section mostly by rote from the article I linked. I’m pretty sure I understand it, but just so you know. There are a few ways of trusting dynamic updates, but since you’ll likely be making them from a host with a changing IP address, the best way is to use a shared secret. That secret is then held on the server and used by the client to identify itself. The configuration above allows hosts in the subdomain to update their own entry, if they have a key (shared secret) that matches the one on the server. This stage creates those keys.
This command creates two files. One will be the server copy of the key file, and can contain multiple keys, the other will be a single file named after the host that we’re going to be updating, and needs to be moved to the host itself, for later use.
ddns-confgen -r /dev/urandom -q -a hmac-md5 -k thehost.home.example.com -s thehost.home.example.com. | tee -a /etc/bind/home.example.com.keys > /etc/bind/key.thehost.home.example.com
The files will both have the same content, and will look something like this,
key "host.home.example.com" {
algorithm hmac-md5;
secret "somesetofrandomcharacters";
};
You should move the file key.thehost.home.example.com to the host which is going to be doing the updating. You should also change the permissions on the home.example.com.keys file,
chown root:bind /etc/bind/home.example.com.keys
chmod u=rw,g=r,o= /etc/bind/home.example.com.keys
You should now return to /etc/bind/named.conf.local and add this section (to use the new key you have created),
// DDNS keys
include "/etc/bind/home.example.com.keys";
With all that done, you’re ready to create the empty zone.
Creating the empty Zone
The content of the zone file will vary, depending on what exactly you’re trying to achieve. But this is the one I’m using. This is created in /var/lib/bind/home.example.com,
$ORIGIN .
$TTL 300 ; 5 minutes
home.example.com IN SOA nameserver.example.com. root.example.com. (
1 ; serial
3600 ; refresh (1 hour)
600 ; retry (10 minutes)
604800 ; expire (1 week)
300 ; minimum (5 minutes)
)
NS nameserver.example.com.
$ORIGIN home.example.com.
In this case, namesever.example.com is the hostname of the server you’ve installed bind9 onto. Unless you’re very careful, you shouldn’t add any static entries to this zone, because it’s always possible they’ll get overwritten, although of course, there’s no technical reason to prevent it.
At this stage, you can recycle the bind9 instance (/etc/init.d/bind9 reload), and resolve any issues (I had plenty, thanks to terrible typos and a bad memory).
Delegation
You can now test your nameserver to make sure it responds to queries about the home.example.com domain. In order to properly integrate it though, you’ll need to delegate the zone to it, from the nameserver which handles example.com. With Gandi, this was as simple as adding the necessary NS entry to the top level zone. Obviously, I only have a single DNS server handling this dynamic zone, and that’s a risk, so you’ll need to set up some secondaries, but that’s outside the scope of this post. Once you’ve done the delegation, you can try doing lookups from anywhere on the Internet, to ensure you can get (for example) the SOA for home.example.com.
Making Updates
You’re now able to update the target nameserver, from your source host using the nsupdate command. By telling it where your key is (-k filename), and then passing it commands you can make changes to the zone. I’m using exactly the same format presented in the original article I linked above.
cat <<EOF | nsupdate -k /path/to/key.thehost.home.example.com
server nameserver.example.com
zone home.example.com.
update delete thehost.home.example.com.
update add thehost.home.example.com. 60 A 192.168.0.1
update add thehost.home.example.com. 60 TXT "Updated on $(date)"
send
EOF
Obviously, you can change the TTL’s to something other than 60 if you prefer.
Automating Updates
The last stage, is automating updates, so that when your local IP address changes, you can update the relevant DNS server. There are a myriad ways of doing this. I’ve opted for a simple shell script which I’ll run every couple of minutes via cron, and have it check and update DNS if required. In my instance, my public IP address is behind a NAT router, so I can’t just look at a local interface, and so I’m using dig to get my IP address from the opendns service.
This is my first stab at the script, and it’s absolutely a work in progress (it’s too noisy at the moment for example),
[sourcecode language=”bash”]#!/bin/sh
# set some variables
host=thehost
zone=home.example.com
dnsserver=nameserver.example.com
keyfile=/home/bob/conf/key.$host.$zone
#
# get current external address
ext_ip=`dig +short @resolver1.opendns.com myip.opendns.com`
# get last ip address from the DNS server
last_ip=`dig +short @$dnsserver $host.$zone`
if [ ! -z "$ext_ip" ]; then
if [ ! -z "$last_ip" ]; then
if [ "$ext_ip" != "$last_ip" ]; then
echo "IP addresses do not match (external=$ext_ip, last=$last_ip), sending an update"
cat <<EOF | nsupdate -k $keyfile
server $dnsserver
zone $zone.
update delete $host.$zone.
update add $host.$zone. 60 A $ext_ip
update add $host.$zone. 60 TXT "Updated on $(date)"
send
EOF
else
echo "success: IP addresses match (external=$ext_ip, last=$last_ip), nothing to do"
fi
else
echo "fail: couldn’t resolve last ip address from $dnsserver"
fi
else
echo "fail: couldn’t resolve current external ip address from resolver1.opendns.com"
fi[/sourcecode]
