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