DNS & DHCP High Availability: Pi-hole, BIND9, Infoblox & Anycast

1. The Fallacy of Static Primary/Secondary DNS in Operating Systems

A common misconfiguration in small-to-medium enterprise networks is specifying two static DNS IP addresses (e.g., 10.10.10.10 and 10.10.10.11) in client DHCP lease options, assuming that the secondary server will instantly take over if the primary server fails.

In reality, standard operating system resolver libraries (Windows DNS Client, macOS mDNSResponder, Linux glibc/systemd-resolved) exhibit unpredictable and sluggish failover behavior. When a primary DNS server stops responding (e.g., during a system crash or power outage), the operating system typically waits for a timeout period of 1.0 to 3.0 seconds per DNS query before failing over to the secondary address. Because modern web browsers, enterprise SaaS applications, and operating systems execute dozens of parallel DNS lookups simultaneously, users experience massive application freezes, timeout errors, and broken web assets. If the primary server accepts TCP connections but hangs on resolution, client queries may stall indefinitely.

2. The Enterprise Solution: BGP Anycast Active-Active DNS Architecture

To achieve instantaneous, hitless DNS failover with true active-active load balancing, enterprise infrastructure deploys Anycast Routing via Border Gateway Protocol (BGP).

In an Anycast architecture, two or more physically independent DNS server nodes (running BIND9, PowerDNS, or enterprise appliances like Infoblox) are assigned the exact same virtual IP address (e.g., 10.10.10.1) on their loopback interfaces (lo:0). Each DNS server runs a local BGP routing daemon (such as BIRD or FRRouting) that peers directly with the enterprise core Layer 3 switches.

3. Split-Horizon DNS Engineering with BIND9 Views

Enterprise organizations frequently maintain internal web portals, ERP systems, and file servers whose hostnames mirror public internet domain names (e.g., portal.enterprise.com). Exposing internal RFC 1918 private IP addresses to public internet DNS records represents a critical security reconnaissance vulnerability. Conversely, routing internal LAN users through public internet gateways to access local servers creates unnecessary hair-pinning and bandwidth bottlenecks.

Split-Horizon DNS utilizes BIND9 view clauses to serve completely different DNS zone records depending on the source IP address of the querying client:

// BIND9 named.conf Split-Horizon Configuration
acl "internal-networks" {
    10.10.0.0/16;
    172.16.0.0/12;
    localhost;
};

view "internal" {
    match-clients { "internal-networks"; };
    recursion yes;

    zone "enterprise.com" {
        type master;
        file "/etc/bind/zones/db.enterprise.internal";
    };

    include "/etc/bind/named.conf.default-zones";
};

view "external" {
    match-clients { any; };
    recursion no;

    zone "enterprise.com" {
        type master;
        file "/etc/bind/zones/db.enterprise.external";
    };
};

When an internal workstation on VLAN 20 queries portal.enterprise.com, the BIND9 internal view matches the ACL and resolves the request to the local high-speed server IP (10.10.10.50). When a remote user on the public internet queries the exact same hostname, the external view returns the public reverse-proxy IP (203.0.113.25), enforcing Cloudflare or perimeter NGFW inspection.

4. DHCP High Availability: ISC Kea HA Failover Protocols

Unlike DNS, where Anycast permits multi-node active-active serving, DHCP operates over broadcast/unicast UDP ports 67 and 68 and requires strict state synchronization to prevent IP address conflicts. If two uncoordinated DHCP servers issue leases on the same subnet, both will inevitably assign the same IP address to two different devices, generating catastrophic ARP collisions.

Modern enterprise IPAM relies on ISC Kea (the high-performance successor to legacy ISC DHCPd) running a stateful High Availability hook library. Kea HA operates in two primary topologies:

• Load-Balancing Mode (Active-Active): Both Kea servers process client DHCPDISCOVER packets concurrently. A deterministic hash of the client's MAC address assigns 50% of the pool to Server A and 50% to Server B. Before either server issues a DHCPACK, it replicates the lease state to its peer via a dedicated high-speed RESTful JSON API. If either server detects a heartbeat failure, the surviving node automatically claims 100% of the address pool.
• Hot-Standby Mode (Active-Passive): Primary server handles all leases. The standby server receives real-time lease updates and steps in only when the primary node misses three consecutive heartbeats.

5. Cryptographic Integrity: DNSSEC Validation

Standard DNS queries travel over plaintext UDP, leaving enterprise networks vulnerable to DNS cache poisoning (Kaminsky attacks) and rogue captive portal redirection. Enabling DNSSEC (DNS Security Extensions) on internal recursive resolvers cryptographically validates the authenticity of resolved records.

DNSSEC establishes a hierarchical chain of trust originating from the Internet Assigned Numbers Authority (IANA) root zone trust anchor (KSK-2017). Each zone publishes Resource Record Sets (RRsets) signed by a Zone Signing Key (ZSK) in an RRSIG record. The authoritative parent zone validates the child zone via a Delegation Signer (DS) record containing a SHA-256 hash of the child's Key Signing Key (KSK). If an upstream attacker attempts to inject a fraudulent IP address for an external bank or SaaS vendor, the recursive resolver detects an invalid cryptographic signature (SERVFAIL) and drops the poisoned response, protecting internal users from credential harvesting.

Frequently Asked Questions