Dynamic DNS (was Re: h2n 2.38)

Kevin Darcy kcd at daimlerchrysler.com
Fri Jun 15 19:57:55 UTC 2001


Brad Knowles wrote:

> At 12:19 PM +0100 6/15/01, Jim Reid wrote:
>
> >  I disagree. Unless DDNS is used sensibly, it can cause far bigger
> >  problems than it supposedly solves. Lack of proper audit trails, weak
> >  change controls, scaling, security, and inconsistent zone integrity
> >  (eg CNAME and other data errors) are just some of the problems that
> >  can arise from ill-judged use of DDNS.
>
>         And what about locking?  Normally, when we talk about a database
> system that might have multiple different clients accessing it and
> updating it simultaneously, we talk about things like ACID
> (atomicity, consistency, isolation, durability), and whether a
> particular database includes record locking, two-phase commit,
> rollback, etc....  I don't see any of these kinds of features being
> available internally to BIND.
>
>         BIND is good for what it does, but if you want to guarantee
> consistency (and all that), it strikes me that it would be a major
> mistake to attempt to use DDNS as a panacea for problems that some
> freely available SQL databases are still grappling with.

DDNS prereqs provide a certain amount of consistency-enforcement, and you can
use "marker" records for even more. If you need something more ACID-ic than
that, you can always implement it in whatever software drives the Dynamic
Updates, i.e. at a higher level. I'd still rather just implement
consistency-enforcement in my maintenance system, than have to implement
consistency-enforcement *and* setup and maintain a database engine/subsystem
besides...


- Kevin




More information about the bind-users mailing list