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