Dynamic DNS (was Re: h2n 2.38)

[Brad Knowles]

At 2:43 PM -0400 6/15/01, Kevin Darcy wrote:

>>  Lack of proper audit trails,
>
>  This problem is not specific to the use of DDNS. In fact, at least with
>  DDNS you have an idea in named's logs of what was changed. With a
>  non-DDNS-based maintenance system, like one which spews out zonefiles
>  from an external database e.g. an SQL database, you have no inkling in
>  named's logs as to what has changed in the zone, if anything. Any logging
>  that is done has to be done in the maintenance system itself.

	Of course you build in those kinds of things when you're 
designing a "real" database-driven solution.  The problem is that 
attempting to use DDNS for this means you have no possibility of 
these kinds of controls, unless you do so through wrappers to the 
nsupdate program, and you sock it away somewhere so that no one else 
can find it or use it.

>>  weak
>>  change controls,
>
>  Ditto. This problem is not specific to the use DDNS.

	No, but the DDNS makes it impossible to implement, without a wrapper.

>>  scaling,
>
>  Not sure what is meant here. If anything, DDNS would seem to scale better
>  because the changes are made incrementally. Most non-DDNS maintenance
>  systems I've seen -- including my old legacy system that I replaced with
>  a DDNS-based one -- reload a whole zone (or even the whole nameserver!)
>  after each update. That's not very scalable for a high frequency of
>  updates.

	Trust me, an Oracle Parallel Server application can be made to 
scale to levels of performance that you could only *dream* about with 
BIND.

>>  security,
>
>  I don't understand this criticism. DDNS updates can be secured with
>  TSIG (or I presume, with DNSSEC in BIND 9) *in*addition*to* whatever
>  security mechanisms you have embedded in the maintenance system itself.

	You don't have fine-grained authentication and control over who 
can update what.  With a proper database solution, you can have 
precisely that, on a per-record and per-field basis, along with 
having it automatically fill in the change log information of who did 
what when, having trivial rollback capability, etc....

	With a pure DDNS solution, you may know what happened and when, 
but you don't know why, by whom, or have any kind of rollback 
capability.

-- 
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,$_)}'