DDNS updates for in-addr.arpa.

[Kevin Darcy]

Waltner, Steve wrote:

> I've run into a problem deploying DDNS on our network related to DDNS
> updates and the in-addr.arpa. domain. I've searched through the archives and
> have found several discussions on using DDNS, but nothing really related to
> this problem. I'm using BIND 8.2.2p7, but could move to BIND 9.0.1 if that
> would help, but reading the docs on BIND 9, it might be even worse.
>
> Current Setup:
> DNS files are edited using a "updt_named" script that was developed locally.
> This script creates a lock file, and than launches vi on the named.data file
> for our local DNS domain (ks.lsil.com). The administrator makes their
> changes to the domain serial number, and then to the actual RR data for the
> domain. Once that's done, the updt_named script logs the changes that were
> made, pipes the named.data file through an awk script that generates two
> different in-addr.arpa zone files, HUPs the named server, wait 5 seconds,
> tail the syslog messages to make sure the changes were OK, and then remove
> the lock file. This has been working fine for strictly static data. All DHCP
> addresses have just had an entry like "dhcp-10-0-0-1 IN A 10.0.0.1" in the
> named.data file.
>
> DDNS Problem:
> The problem is you can't mix dynamic and static data in the same zone. This
> is fine for the A records because I have no problem breaking the DHCP
> addresses out so they are part of a dhcp.ks.lsil.com domain that would be
> strictly managed by DDNS coming from the DHCP server, but there is a problem
> with the PTR records in the in-addr.arpa. domain. How would you merge the
> dhcp.ks.lsil.com and ks.lsil.com A records into a common list of PTR records
> for the in-addr.arpa. domain? The DHCP server manages the dynamic portion of
> this list, but I couldn't keep using my awk script since it wouldn't be able
> to track changes that were done by the DHCP server.
>
> About the only thing I can think to do here would be to switch the
> in-addr.arpa domain to use DDNS, and then develop a script that would look
> at the changes done to the static file, and make the necessary changes to
> the PTR records. That's not necessarily going to be the easiest program to
> develop since the named.data file is in free text format.
>
> I've also heard people mention packages for maintaining DNS files strictly
> with DDNS updates. What are some popular programs that could do this. The
> only problem I see with this is that we might loose the flexibility that we
> currently have with people manually editing the named.data file. Our
> named.data file is < 6000 lines, so it's still manageable in a manual
> fashion. I would really miss being able to embed comments in the named.data
> file if we switched to some external program to build the files for us.

I have recently converted the backends of my DNS maintenance systems to use
DDNS for all updates. My big task right now is trying to get my
*different* DNS maintenance systems to update *each*other* in a sane way, which
is actually turning out to be a bigger challenge than just converting each
system to use DDNS insularly.

I have to ask, though: why would you *want* to keep the manual update
process? It seems inherently prone to error. Also, in our environment at least,
often the folks who might want to update DNS on a casual basis
(LAN administrators, router jockeys, etc.) might not be very proficient with
"vi" and would be very uncomfortable having to use it to make their
DNS changes. I have a very simplistic web interface (form-based, CGI
mostly-Perl backend, no Java/Javascript or even frames at this time) that
allows people to make changes. People seem quite happy with this; in fact,
they've been using it for years before I switched the backend to use DDNS, and
so the switch was actually transparent to them. Since the interface is so
minimalistic, it's even usable over low-speed dialup links and/or backlevel
browsers, which in our case is a plus.

As for losing the comments in your zone files, what are you using those
comments for? Change histories, audit logs, a repository of
non-DNS-information? Call me a purist, but I don't think that kind of thing
really belongs in zone files. Maintaining that information *in*parallel* with
your DNS updates is fine, IMO (using an LDAP directory, an RDBMS, separate flat
files, syslog, whatever) but I don't think it's a good idea to store it in the
zonefiles themselves. (And just so you don't think this is a case of sour
grapes, I had adopted that policy long before I ever considered switching to
DDNS for maintenance).


- Kevin