Advice on Bind9/ISC DHCP cluster

Grant Taylor gtaylor at
Sat Mar 27 06:40:20 UTC 2021

On 3/25/21 9:19 AM, Olivier wrote:
> Hello,


> I would like to implement a 3 hosts cluster with the following features:

I don't see anything conceptually wrong with what you've outlined. 
Though I wouldn't call it a "cluster".  To me a cluster is something 
that is (as largely as possible) self redundant meaning no Single Point 
of Failure.  You are SPoFed on host1.

> 1- host1 is a bind9 master
> 2- host2 is a bind9 slave/ISC DHCP primary
> 3- host3 is a bind9 slave/ISC DHCP secondary
> 4- primary ISC DHCP instance sends dynamic updates to bind9 master
> 5- secondary ISC DHCP instance sends dynamic updates to bind9 master
> 6- DNS clients queries Bind9 slaves (hosts 2 and 3)
> 7- DNS updates are made on Bind9 master

I assume that you are thinking that the DHCP server will be sending the 

It's probably worth pointing out that the bind9 secondaries (host2 & 
host3) can be configured to forward any dynamic updates which they 
receive on to the primary (host1).  This is germane when clients send 
dynamic updates to the DNS server(s) that they are querying.  IMHO 
Windows is (at least used to be) notorious for doing this.

> I can accept to loose (either static or dynamic) updates if host1 
> is down

This is the SPoF that I was talking about.

You also need to be mindful of your expiration timers on your zone(s). 
What if the primary server is down for 8 days (for reasons) and the 
secondaries honor a zone expiration time of 7 days?

> 1. Is it possible to implement both 4 and 5 ?

I would assume that #4 can be done.

I would expect that #5 can be done.

> 2. Any alternative architecture (I can use up to 5 hosts) ?

I /think/ that BIND has some options to use something else, a 
(traditional) DB and / or LDAP for zone information via Dynamically 
Loadable Zones.  Thus you can use replications features in the DB / LDAP 
servers that work to avoid the SPoF of a single primary.

I would highly recommend that you consider VRRP et al. for VIPs that 
clients point to.  That way you can move them between servers as you 
need to have one down for maintenance.  --  I've seen some clients get 
really crochety and not fall back to their second configured DNS server 
nearly as gracefully as I would have hoped.  Having the preferred DNS 
server's VIP re-homed on an alternate system would have allowed the 
client to think that it's preferred server is and responding like 
normal, even if the real host is out of the rack and in pieces on the floor.

Depending on your needed scale you might consider some form of load 
balancing.  --  You can look at some form of ""hardware / ""appliance[1] 
based load balancer or you can look at a host based software solution. 
--  There are a number of solutions in this space.  But they are 
somewhat platform dependent and I don't see any information on what 
platform you're using.

[1] What is ""hardware / ""appliance other than a different host that 
runs software.

Good luck.

Grant. . . .
unix || die

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4013 bytes
Desc: S/MIME Cryptographic Signature
URL: <>

More information about the bind-users mailing list