Dynamic DNS (was Re: h2n 2.38)
Brad Knowles
brad.knowles at skynet.be
Fri Jun 15 12:33:20 UTC 2001
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.
--
Brad Knowles, <brad.knowles at skynet.be>
/* efdtt.c Author: Charles M. Hannum <root at ihack.net> */
/* Represented as 1045 digit prime number by Phil Carmody */
/* Prime as DNS cname chain by Roy Arends and Walter Belgers */
/* */
/* Usage is: cat title-key scrambled.vob | efdtt >clear.vob */
/* where title-key = "153 2 8 105 225" or other similar 5-byte key */
dig decss.friet.org|perl -ne'if(/^x/){s/[x.]//g;print pack(H124,$_)}'
More information about the bind-users
mailing list