We have roughly 1,000 Linux servers, 1,000 Windows clients, a few hundred Windows servers, and a Kubernetes cluster. They use one load-balanced DNS endpoint backed by three AD-integrated DNS servers.
Load is uneven, some domain controllers get CPU spikes, and DNS registrations aren't always consistent across them. Would it be simpler to configure clients with multiple DNS servers directly, or is there a better way to keep a stable endpoint?
I'd start by testing direct access to multiple DNS servers rather than assuming the load balancer is buying you much. Windows clients can be configured with more than one resolver, and DHCP, Group Policy, or configuration management can help distribute changes. AD Sites and Services can also help clients find appropriate domain controllers, though it doesn't replace configuring DNS servers.
Test actual failover with your client versions and applications. A secondary DNS address isn't a guarantee that every failure will be handled the way you expect. Also check capacity and query rates before deciding whether three servers are enough.
A load-balanced DNS endpoint can be made to work, but a generic flow-based policy won't necessarily spread query cost evenly. One busy client or a small number of persistent flows can land on the same backend. Measure queries by client, query type, backend, and response time before changing the design.
Check both UDP and TCP handling, health checks, timeouts, and whether source addresses are preserved. Kubernetes DNS traffic is worth examining too, since a forwarding or caching configuration there can concentrate a lot of queries behind a few source addresses. A DNS-aware load balancer or anycast is an option, but either adds operational complexity.
The registration issue needs its own investigation. AD-integrated zones replicate between domain controllers, so a record can exist on one DNS server before it appears on another. Routing successive queries or updates to different servers can make that delay more visible, but it doesn't prove the load balancer caused it.
Check AD replication health, the zone's replication scope, dynamic update settings, and which server receives each update. Compare timestamps and results directly against each backend rather than only querying the shared address.
Another option is a pair of local caching resolvers, with AD DNS reached through conditional forwarding for the relevant zones. That can reduce repeated query traffic and give clients stable resolver addresses without putting a generic load balancer directly in front of every DC.
Don't treat that as a transparent swap, though. Check how dynamic updates reach the authoritative AD DNS servers, and test AD discovery, reverse lookups, caching behavior, and resolver failure. DDI appliances are another possible route if you need the broader DNS and address management features, but they may be more than this problem requires.
If changing client addresses is the main concern, look at using service IP addresses that can be moved when a DNS server is replaced. That keeps a stable address without necessarily balancing every query. Plan the failover and test how clients behave while the address moves.
Answers are reviewed before publication.
counting_wobbly_chairs:
Linux resolver behavior varies too, so test it separately rather than assuming it will react like Windows when a server stops responding.