Advice on Bind9/ISC DHCP cluster

[Grant Taylor via bind-users]

Hello,

Hi,
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
updates.

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.