A Couple of web-nsupdate Implementation Hints

Instead, I recommend putting your dynamic clients into their own zone. That is, call the host something like host1.dyn.example.com instead of host1.example.com, create a new zone called dyn.example.com, and put the update-policy configurations there.

There are two reasons why I recommend this. First, I think it is more secure to segregate your dynamic clients. In the event of problems (such as a typo in the configuration permissions), you won't affect other critical resources in the zone, such as mail and web servers. Second, and most critically, I've had instances where the BIND9 journal wouldn't replay on startup, and the nameserver failed to load and serve the zone. That's a big deal, it can render your hosts unreachable.

I fixed that problem by creating an empty zone to hold the dynamic hosts, rather than putting them in the main zone. Now when I restart the nameserver, the journal replay runs reliably. It's completely possible that this is all due to a stupid configuration problem I made—but that harkens back to point one: you don't want configuration problems with the dynamic clients breaking the critical servers in your zone.

To implement this, I added records to the main zone similar to these:

dyn     NS      ns.example.com.
host1	CNAME   host1.dyn	;; host1.example.com short for host1.dyn.example.com
host2	CNAME	host2.dyn	;; host2.example.com short for host2.dyn.example.com

You must have NS "glue" records for all of the nameservers that will serve the dynamic zone. You'd typically want more than one, but I'm not running any public services from dynamic addresses so I didn't bother. That saves a bunch of update traffic to my secondary nameservers.

I also put in CNAME records as a convenience. That way I don't have to spell out the dyn zone component; I can just say host1.example.com to specify the host.

You'll also need to create an empty zone file for the new dyn.example.com zone. It should just have the SOA record and NS records to match the glue records in the parent zone.

Finally, when you add this new zone to your named.conf file, you'll need to say something like:

zone "dyn.example.com" {
	type master;
	file "zone-dyn.example.comt";
	allow-query { any; };
	update-policy {
		grant web-nsupdate. name host1.dyn.example.com. A;
		grant web-nsupdate. name host2.dyn.example.com. A;

Now, on to the client side hint. This applies if you are using OpenWrt.

It's really easy to integrate web-nsupdate into the router configuration, but it does require a change to a script. Here is the procedure:

  1. Log into the router.
  2. Edit the /usr/share/udhcpc/default.script file.
  3. Find the renew/bound clause. At the end, just before the ";;", add the web-nsupdate request.

The web-nsupdate request should look something like this:

This will send a DNS update every time the host address is set or renewed by DHCP. I previously discussed what that wget command does. Here, I'm piping the output into logger so that update errors are recorded.

I've implemented all of the things discussed here in my web-nsupdate configuration. It has worked reliably and without incident for months. Now when I'm working remotely, I can easily ssh back into my home network.