A second domain controller is the most common high-availability decision in a district, and it is usually made for the right reason and implemented with one detail missing: the clients were never told to use it, or it holds a different configuration, or both live on the same hypervisor.
High availability is not "there are two." It is "one can fail and nobody notices, and you have tested that."
The three core services and their failure shapes
| Service | What fails | What users see |
|---|---|---|
| DNS | One resolver down, or a stale zone | Slow page loads, then failures after the resolver timeout |
| DHCP | Scope exhausted, server down, relay missing | 169.254.x.x, "no internet" |
| NTP | Clock drift beyond five minutes | Logins fail with Kerberos errors that mention nothing about time |
Each one needs a different kind of redundancy, and all three need the same thing: a monitor that performs the actual transaction rather than checking whether a process is running.
Active Directory and DNS together
Domain controllers host both. Design rules that matter more than the vendor guidance:
- Two DCs, different hosts. Two VMs on the same Proxmox node are one DC with extra steps.
- Both are DNS servers, and both are listed in DHCP option 6, in a consistent order.
- Both register their SRV records in the same AD-integrated zone; replication handles the rest.
- Time comes from the PDC emulator, which should sync from a reliable external source, and the other DC should sync from it.
If one DC dies and clients only knew about that one, everything appears broken even though a healthy DC is running. That is a DHCP option problem, not an AD problem.
DHCP failover
| Mode | Behavior | When to use |
|---|---|---|
| Hot standby | One active, one passive, state replicated | Most districts; simple to reason about |
| Load balance | Both answer, percentage split | Large pools where both servers should work |
| Split scope | Each owns part of the range | Legacy; avoid on new designs |
Windows DHCP failover replicates leases, so a client that renewed on server A is known to server B. Without it, two servers hand out overlapping addresses and the duplicate is invisible until a device stops responding.
Failover does not replicate options
In some configurations, scope options are replicated; reservations and policies may not be. After any change, compare the two servers' effective configuration, not just their service state.
NTP: the service nobody lists
Kerberos tolerates five minutes of clock skew. Beyond that, authentication fails with errors about "clock skew too great" or, worse, generic logon failures.
- The PDC emulator syncs from an external source (or a GPS clock).
- Other DCs sync from the PDC.
- Switches and APs sync from an internal source, not from the internet.
- Cameras and IoT devices often ignore DHCP option 42 and need their own NTP setting.
A district with a drifting hypervisor clock can spend a week chasing authentication problems that are really one NTP source.
Monitoring that proves the service works
| Check | What it proves | Frequency |
|---|---|---|
| DNS query for a known internal name from each VLAN | Resolution path end to end | 1 minute |
| DNS query for a known external name | Forwarder path | 1 minute |
| DHCP test lease on a lab VLAN | Scope, relay, and server | 5 minutes |
| NTP offset on the PDC and one member server | Time hierarchy | 5 minutes |
| Certificate expiry for LDAPS, VPN, and web | Nothing expires silently | Daily |
Service-state monitoring ("the DNS service is running") catches almost nothing. Query monitoring catches the failures users actually experience.
Worked example: DC1 fails at 08:10
What should happen:
- Clients with DC1 first in their resolver list time out once, then try DC2. Browsing pauses for a second or two, then continues.
- Kerberos tickets already issued keep working until they expire; new logins go to DC2.
- DHCP, if it is on DC1 with failover, continues on DC2 with replicated leases.
- NTP: if DC1 held the PDC role, time still comes from DC2 (which syncs from DC1 until the role moves). If DC1 is gone for long, seize the role.
What actually happens in most districts: step 1 works, step 3 was never configured, and every device
that renews gets 169.254.x.x an hour later. The second DC was there; the DHCP service was not.
What breaks in production
- Both DCs on one host. A hypervisor reboot takes out DNS and authentication at once.
- DHCP without failover, running on the DC that is allowed to fail.
- Option 6 listing only one resolver, so the second DC is decorative.
- NTP blocked at the firewall, so the PDC drifts and Kerberos fails weeks later.
- Monitoring that pings the server instead of querying the service.
Checklist
- Two DCs on separate hosts, both hosting DNS, both in DHCP option 6.
- DHCP has a failover relationship, and a test lease has been taken from each server.
- The PDC emulator has a working time source, and member servers sync from it.
- Synthetic DNS and DHCP checks run from at least two VLANs.
- Certificate expiry is monitored with at least 30 days of warning.
- Someone has actually shut one DC down during a maintenance window and watched what happened.
Next
The design is only as good as its failure modes. Continue with Core Services Failure Modes, the symptom-to-cause table worth keeping open during an incident.