For applications that authenticate against an Active Directory DC, obviously it would be best to just point them to the main domain DNS record rather than a specific DC for failover, load balancing, etc.
What are best practices for those applications that force you to hardcode a DC's IP? We could hard code a load balancer's IP address instead so if one DC went down that application would still be able to authenticate. Are there any better alternatives?
Active Directory already has load balancing techniques built into it. Your Windows client knows how to locate the redundant domain controllers in its own site, and how to use another one if the first one is unavailable. There's no need to perform additional load balancing, like "clustered" DCs, etc. as long as you have redundant DCs.
In a way, you can think of an Active Directory Site as a "load balancer," because clients in that site will randomly pick one of the DCs in the same site. If all the DCs in a site fail or if the site has no DCs, then the clients will pick another site (either next-closest site or at random.)
You can load balance Active Directory-provided DNS service for domain-joined clients by putting a VIP on a hardware load balancer, and having that VIP load balance between several of the domain controllers. Then on your clients, put that VIP as the preferred DNS server in the TCP/IP configuration.
I'm doing that right now for a global infrastructure and it's working great.
But that only applies to DNS service.
Don't try to load balance your domain controllers for authentication. It's asking for trouble. You would at the least have to do a lot of complex custom SPN work and you'd be throwing yourself way out of Microsoft support boundaries. From this blog, which you should read, I will quote him:
Go back to the vendors and tell them you don’t consider them to be AD Integrated and you will find a different solution.
Now as for applications that ask you to type in the IP address of a domain controller? Well, I'll just reiterate my comment:
Whoever wrote an application that forces you to hardcode the IP address of a domain controller into it doesn't know what he or she is doing.
there has never been a good reason to hardcode an IP or use an IP to resolve AD queries. There are no best practices for bad practices.
Several of the other answers to this question seem to assume there is no other world than Microsoft aware applications. Unfortunately this isn't the case, as evidence by the original question:
What are best practices for those applications that force you to hardcode a DC's IP?
While Microsoft does not support or recommend using a NLB solution in front of Active Directory there does indeed appear to be some options for authenticating non-Microsoft AD aware applications.
An actual need for external "Load balancing" AD is rare, and it is difficult to do properly. A need for typical queries may work fine, however a typical Windows client and applications need to perform updates. A Windows client attempts to establish an affinity with a particular dc, so that if it updates something and immediately attempts a subsequent operation, it hits the same dc. Application developers do the same thing. If you write code that creates a user account, then attempt to change the password on that account 1 ms later, you need to hit the same dc.
If you were to front-end AD with some load balancer solution, you take ownership of ensuring those approaches and affinities dont break.
If the need is availability, as opposed to balancing load, clustering may be more appropriate (cluster can of worms aside).
In large AD implementations, a more traditional approach is to identify the majority consumers, and put them in a site with their own dc's. For example, if you have five Exchange servers, create a site for the subnets for those servers, and put dedicated GC's in that site. Same would apply for other servers such as SharePoint.
