Dynamic DNS (was Re: h2n 2.38)

[Kevin Darcy]

Brad Knowles wrote:

> 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.

Well of course you'd have a "wrapper" (or as I prefer to speak of it, a middle
tier)! It would be the height of irresponsibility to just put "allow-update {
any; };" on your zones and tell your junior admins to go wild with nsupdate.
That kind of ridiculous implementation is a straw man argument. To me, DDNS is a
*backend* to a maintenance system. Nothing more. All of the access control,
consistency-checking, logging, change control, etc. is done at the higher
levels. You could even use an SQL database to keep track of things, if your
heart desires. DDNS is just the interface between the rest of your maintenance
system and named's resource-record database.

As for socking away stuff "so that no one else can find or use it", how is this
in any way dependent on what backend is in use?

> >>  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.

Well, how many updates-per-sec does any DNS maintenance system need to scale to
*for*a*single*zone*? I'm having trouble imagining a scenario where this number
would be very high (other than misguided attempts to use DNS for highly-dynamic
load-balancing). So if you don't really need all of that Oracle horsepower for a
single zone, the question then becomes, how cost efficient is the Oracle
approach when you're hosting *many* zones, versus just splitting those zones up
between a bunch of master servers? (And lest we forget, individual website names
can be split off into their own zones if necessary).

> >>  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.

I don't think that anyone in their right mind would implement a
"pure" DDNS solution, as you're caricaturing it. That's certainly not what I've
been advocating.


- Kevin