DDNS updates for in-addr.arpa.

[Waltner, Steve]

We use comments in the DNS file to remind those modifying the zone file what
IP ranges are supposed to be used for. (ie, NT servers, desktop system,
engineering servers, x terminals, disk arrays, lab test systems, etc...) I
don't necessarily need to maintain the current setup, but do need a viable
alternative that would integrate well with a DHCP making changes in
parallel.

Are there any suggestions for a management system that meets the following
criteria:
- DDNS based updates to zone file
- web interface preferred, command-line OK
- Automatically generates/deletes PTR records when an A record is
generated/deleted
- When doing an update on an existing record, queries and finds all RRs for
a given name (we use A and MX on every name, and several have TXT RRs as
well) to show user what currently is setup for that name

Kevin, are your CGI scripts available for me to get a jump start on the
work? Does anyone else want to offer up their own set of scripts as a
starting point?

--
Steve Waltner
LSI Logic
Steve.Waltner at lsil.com

> ----------
> From: 	Kevin Darcy
> Sent: 	Wednesday, December 20, 2000 1:38 PM
> To: 	'bind-users at isc.org'
> Subject: 	Re: DDNS updates for in-addr.arpa.
> 
> 
> 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
> 
> 
> 
> 
> 
>