* Jerry Feldman (gaf@blu.org) [030506 12:06]:
A subsidiary zone file might be fubar.foo.bar containing just the A record for fubar, and the appropriate serial number/expriation times et. al.
$INCLUDE /path/to/fubar.foo.bar.a.records You may need to set set $ORIGIN on $INCLUDE as well depending on how the zone is configured, etc.
Right now, fubar.foo.bar is a CNAME for hxx.xx.xx.xx.cablemodem.net.
You mean fubar.foo.bar's cname is hxx.xx.xx.xx.cablemodem.net, right?
In the future, I want to allow those hosts to check their own IP addresses, when they detect a change, upload the new ip address to the server, and a cron script on the server will update the zone file and restart named.
You could also write a shell or perl daemon that monitors the dhcp lease database for changes, that way you don't have to worry about races or maintaining so many clients.
I could easily do this now with the main zone file, but my partner is nervous about that since we run the risk of trashing the main zone file. By segmenting it, any damage that would be done would be contained.
That's a legitimate concern I guess. A cleaner solution (but with more setup) would be to allow the clients to update the zone themselves using TSIG keys. There's a nice example here: http://ops.ietf.org/dns/dynupd/secure-ddns-howto.html#forward -- -ckm