DDNS updates for in-addr.arpa.

[Waltner, Steve]

I had alluded to this in the my first two e-mails, but the reason I want a
DDNS based update mechanism, even for our "static" data is outlined in
section 4.1 of the BIND ARM which can be found in /doc/arm of the BIND 9.0.1
distribution:

======================================
The zone files of dynamic zones must not be edited by hand. The zone file on
disk at any given time may not contain the latest changes performed by
dynamic update. The zone file is written to disk only periodically, and
changes that have occurred since the zone file was last written to disk are
stored only in the zone's journal (.jnl) file. BIND 9 currently does not
update the zone file when it exits as BIND 8 does, so editing the zone file
manually is unsafe even when the server has been shut down.
======================================

Using DDNS updates makes hand editing of the zone file impractical for both
BIND 8 and BIND 9. You can edit the actual zone file for BIND 8, iff the
named server is not currently running because it flushes the zone file out
to disk. This is not convenient, because it is a dump format of the zone
which has the hosts in a pseudo random order, which makes it very difficult
to find the next available IP address in a zone file that contains several
thousand hosts. In BIND 9, editing the zone file is ruled out all together
from the above statement. This is not a problem for most records (A, HINFO,
TXT, MX) because that information can be split into two domains
(dhcp.foo.com which is managed via DDNS from the DHCP server, and foo.com
which contains your static IP addresses where you edit the zone file
directly).

The problem comes with the PTR RRs in the in-addr.arpa. domain. Let's say
you have static IPs for 192.168.1.1-192.168.1.100 and then DHCP addresses
for 192.168.1.101-192.168.1.254. You now need to merge PTR records that are
coming from both your foo.com and dhcp.foo.com zones into a common
1.168.192.in-addr.arpa. zone. You can't mix and match dynamic updates and
zone file editing in a single zone, so you are stuck doing DDNS updates to
your in-addr.arpa. zone even for the hosts coming from foo.com. If you are
going through the hassle of generating DDNS updates for the PTR records for
foo.com addresses, you may as well be making your actual changes to foo.com
with DDNS updates as well. If you're going to develop a DDNS based method of
maintaining your DNS data, you may as well put a fancy web interface on it
(much easier than using vi :-).

Kevin, please send whatever information you feel you can share about your
system. There was one other request for this info, so sharing it with the
list would be a good idea. I would particularly like to see some HTML files
that show the user interface for RR creation, editing, and deletion.

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

> ----------
> From: 	peter at icke-reklam.ipsec.nu.invalid.lsil.com
> Sent: 	Friday, December 22, 2000 3:37 AM
> To: 	comp-protocols-dns-bind at moderators.isc.org
> Subject: 	Re: DDNS updates for in-addr.arpa.
> 
> 
> Waltner, Steve <swaltner at lsil.com> wrote:
> > 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
> viab=
> le
> > alternative that would integrate well with a DHCP making changes in
> > parallel.
> 
> > Are there any suggestions for a management system that meets the
> followi=
> ng
> > criteria:
> > - DDNS based updates to zone file
> Isn't this two different topics involved here ?
> - update of zone file and
> - method of updating
> 
> Is there any specifical reason you want the update to happen with
> DNS Update messages instead of changes in a master file ?
> 
> (just curious )
> Peter h
> 
> > - 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.
> >>=20
> >>=20
> >> Waltner, Steve wrote:
> >>=20
> >> > 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
> archi=
> ves
> >> and
> >> > have found several discussions on using DDNS, but nothing really
> rela=
> ted
> >> 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.da=
> ta
> >> 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
> f=
> or
> >> 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.
> A=
> ll
> >> DHCP
> >> > addresses have just had an entry like "dhcp-10-0-0-1 IN A 10.0.0.1"
> i=
> n
> >> 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
> woul=
> d
> >> 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
> change=
> s
> >> to
> >> > the PTR records. That's not necessarily going to be the easiest
> progr=
> am
> >> 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
> t=
> hat
> >> 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
> u=
> s.
> >>=20
> >> 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
> wa=
> y,
> >> which
> >> is actually turning out to be a bigger challenge than just converting
> e=
> ach
> >> system to use DDNS insularly.
> >>=20
> >> 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
> a=
> t
> >> 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)
> th=
> at
> >> allows people to make changes. People seem quite happy with this; in
> fa=
> ct,
> >> they've been using it for years before I switched the backend to use
> DD=
> NS,
> >> 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.
> >>=20
> >> As for losing the comments in your zone files, what are you using
> those=
> 
> 
> >=20
> >> 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,
> separ=
> ate
> >> 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
> so=
> ur
> >> grapes, I had adopted that policy long before I ever considered
> switchi=
> ng
> >> to
> >> DDNS for maintenance).
> >>=20
> >>=20
> >> - Kevin
> >>=20
> >>=20
> >>=20
> >>=20
> >>=20
> >>=20
> 
> 
> 
> 
> 
> --=20
> Peter H=E5kanson               Phone     +46707328101       Fax
> +463122319=
> 0
> IPSec sverige                Email      peter at ipsec.nu=20=20
> "Safe by design"             Address    Bror Nilssons gata 16
> Lundbystran=
> d
>                                         S-417 55  Gothenburg
> Sweden=20=20=
> =20=20=20=20=20=20=20
> 
> 
> 
>