Bind and DHCP

[Grant Taylor]

On 1/8/25 10:14 AM, John Thurston wrote:
> You may want those services co-hosted today. But if you want to separate 
> them next year, your life will be easier if they had unique IP addresses 
> from the start.

I agree that different IPs for each service is more flexible.

Though I've never found it difficult to move DHCP to another system. 
Unless you're using DHCP helpers / forwarders, I've found that DHCP 
service is effectively IP agnostic.  You just need a system (or helper / 
forwarder) in the L2 broadcast domain to receive the DHCP messages from 
clients.  --  I can't remember any time I cared about the DHCP server's 
IP in the last two decades, other than DHCP helpers / forwarders.

I'm sure there are some edge cases that I'm not thinking of.  I'd be 
curious to learn edge cases others have run into.

As others have said, running BIND and DHCP on the same system shouldn't 
be a problem at all.

I agree with the recommendation of running both BIND and DHCP on a pair 
of systems.  That way there are two instances of each for redundancy.

Though, I would suggest looking into something like VRRP -- possibly via 
keepalived -- for BIND redundancy.  I've had too many problems where 
clients get really unhappy and stall for 15-45 seconds if they can't 
reach their primary DNS server.  VRRP (keepalived) allows you to have 
the DNS service (virtual) IPs float between systems.  Ideally, each 
service VIP is on it's primary / home system.  But in the event of an 
outage, the service VIP can automatically re-home to the backup system. 
Thus clients think they can still get to their primary DNS server 
without any problem / delay.

You may want to load balance clients across the two DNS servers. 
Usually this is easiest if you have different client address ranges 
(subnets) prefer different servers.; 192.0.2.0/24 uses ServerA as 
primary and ServerB as secondary while 198.51.100.0/24 uses ServerB as 
primary and ServerA as secondary.



-- 
Grant. . . .
unix || die