Dynamic DNS (was Re: h2n 2.38)

[Jim Reid]

>>>>> "Brad" == Brad Knowles <brad.knowles at skynet.be> writes:

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

    Brad> 	And what about locking?  Normally, when we talk about
    Brad> a database system that might have multiple different clients
    Brad> accessing it and updating it simultaneously, we talk about
    Brad> things like ACID (atomicity, consistency, isolation,
    Brad> durability), and whether a particular database includes
    Brad> record locking, two-phase commit, rollback, etc....  I don't
    Brad> see any of these kinds of features being available
    Brad> internally to BIND.

That's because they are not really needed to implement DDNS. Either a
dynamic update succeeds or it fails. The issue of synchronisation
shouldn't arise either. A zone has only one master server and all the
update requests for it have to be processed there. That server can
serialise those incoming requests: for instance by ensuring only one
DDNS request is in progress for a zone at any given moment. So in
essense each DDNS request can be considered an atomic transaction --
"add/remove/change these RRs provided these other RRs exist (or don't
exist)" -- with a clearly defined outcome.