Multi-mastering with dynamic updates

[Kevin Darcy]

On 5/17/2010 4:13 PM, Linux Addict wrote:
>
>
> On Mon, May 17, 2010 at 12:48 PM, Phil Mayers <p.mayers at imperial.ac.uk 
> <mailto:p.mayers at imperial.ac.uk>> wrote:
>
>     On 17/05/10 16:59, Arcan_- wrote:
>
>         Thanks for the reply.
>
>             Interesting. What's the use-case for this?
>
>
>         I have a few hundreds of dhcp clients and a two nodes pseudo
>         cluster (for the VIP).
>         I need a solution that enable high availability on the same
>         level of service.
>
>         That way, if one node fails, the other can fully take over.
>
>             You are presumably aware that you can do
>             "allow-update-forwarding" on
>             slaves and they'll forward UPDATE packets to the master (and
>             presumably
>             then receive NOTIFY and do an IXFR to receive the updated
>             zone)?
>
>
>         If the master fails I'm screwd :/
>
>
>     Ah. Sorry, no idea then.
>
>
> Is it possible to put couple of BIND Servers behind a load balancer 
> and both of them act as authoritative to accept DDNS?
Of course. Just configure them both as "master" with an allow-query for 
the zone.That's not the hard part. The hard part is synchronizing those 
changes in some rational way between the "masters" in real-time or 
near-real-time, so that the clients get a consistent view of the DNS 
namespace.
>
> Question to BIND Engineering? Is there a plan to add Multi-Master 
> functionality to BIND in future?
>
> It may not be big deal for people who don't use BIND as Active 
> Directory DNS Server, but its single point of failure, if BIND is used 
> in an AD Environment since DDNS requests will be send to single master.
The simple fact is that Dynamic Update was never defined to meet such 
stringent availability requirements. It was developed as a more elegant 
solution to DNS change management than editing zone files.

If one*really* needs this kind of availability, one ends up having to 
make Dynamic Update just a front-end to some other kind of database, 
which then replicates and synchronizes the dynamic changes, under some 
sort of "conflict resolution" policy (since Dynamic Updates received and 
processed on different "masters" can conflict with each other). This is 
basically the approach taken by Active-Directory-integrated DNS (using 
LDAP as a backend), as well as commercial DNS/DHCP products which use 
database backends such as. Sybase or Oracle.

BIND already has the ability (through the "sdb" interface, see 
doc/misc/sdb) to use alternative database backends, so the door is 
already open for someone to add the Dynamic Update 
processing-synchronization-and-conflict-resolution piece. Whether 
someone has already written such a thing, I have no idea.

I think it is also valid to question where the Dynamic Updates are 
coming from in the first place. Are these updates being generated by 
DHCP lease activity? If so, then you probably want an 
industrial-strength DHCP implementation (which probably uses the *same* 
backend database as the DNS component of the same product) handing all 
of this anyway, because of thorny issues like
-  clients that announce the same computer name for active leases on 
disparate subnets (e.g. a wired versus a wireless connection). Where 
should the A record for computername.example.com point?
-  aging/scavenging of records associated with expired DHCP leases
-  arbitration of whether a name gets assigned to a particular device or 
not (e.g. a laptop acquiring a DHCP lease claims to have the name "www", 
do you blindly repoint your www.example.com A record to point to it?)

                                                                         
                                                     - Kevin

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20100517/0d7be32f/attachment.html>