DDNS updates for in-addr.arpa.

[Kevin Darcy]

peter at icke-reklam.ipsec.nu.invalid wrote:

> Is there any specifical reason you want the update to happen with
> DNS Update messages instead of changes in a master file ?
>
> (just curious )

Well, Peter, I can cite several:

1. Efficiency. Why reload a whole zone on the master just because one record
changes (well, OK, maybe *two* records change -- the actual record and the
SOA serial number reflecting that fact that the zone collectively has changed
-- but you get my point)?

2. Interoperability/Cross-Maintenance. With Dynamic Update, different
maintenance systems can in theory update each other's nameservers. This is
what I'm aiming for. Being able to update reverse data in other organizations'
nameservers, for instance, in response to forward-data changes. And for them
to likewise be able to update my reverse data. This has been a major sticking
point around here, since we have many "mixed" subnets which contain servers
belonging to different organizations hosting different parts of the forward
namespace. With existing maintenance systems, oftentimes the reverse records
are simply dropped, which causes problems for certain applications. In theory
we could "solve" this problem by playing RFC 2317 games, but that has
logistical problems of its own and I think "cross-maintenance" is a more
elegant solution anyway (none of those stupid CNAMEs).

3. Smoother DHCP integration.

4. Win2K integration (assuming that strong authentication isn't required or
that BIND eventually supports GSS-TSIG or Microsoft decides to support RFC'ed
secure update protocols).

5. Simplicity. Anyone who has tried to navigate "nsupdate"s syntax and
comprehend its debug output -- especially when implementing TSIG-authenticated
Dynamic Update as I have -- will probably be surprised to see me list
"simplicity" as a virtue of Dynamic Update. However, these are just
user-interface problems with nsupdate in particular, not with Dynamic Update
_per_se_. In an industrial-strength DNS maintenance system, with double-checks
and failsafes and automatic forward-reverse synchronization, I have found that
it can be simpler to let named do certain "grunt work" tasks like checking
update prerequisites, incrementing the serial number, formatting and writing
out the zone files, etc., through Dynamic Update, than to have to code all of
that crud into the maintenance system oneself. The total amount of code
involved in my maintenance system shrank dramatically when I migrated it to
use Dynamic Update, even as I was adding new functionality. How often do you
see *that* happen?

6. Modularity. The update client can be a completely different machine from
the nameserver, which is a big benefit when your maintenance system is
web-based. Traditionally, I've had to run a web server on my master DNS
server, which sucks up resources and poses a security risk. Now, with
TSIG-authenticated Dynamic Update, I am free to move the web server somewhere
else (of course I still have to protect the copy of the shared key on the web
server, but at least in that case I have a limited amount of data to protect
on an external server and I can lock down the DNS master completely, instead
of having to carefully and selectively protect against *every* potential
security vulnerability a web server presents to my DNS master).

7. Finer Granularity of Security. See the "update-policy" documentation for
BIND 9. Sure, you could embed similar controls into a non-Dynamic-Update-based
maintenance system (and I have), but it's a lot of work. I guess this benefit
could therefore be considered an extension of "Simplicity" then...


- Kevin