"First, load balancing is only performed once for each client at the beginning of a session.
Second, it's possible for the load balancing scheme to get a little skewed.
For instance, all the users that have been sent to MyServer1 may go to lunch while all the users who have been sent to MyServer2 continue to send requests. In this case, one server could become overloaded while another server is sitting by idly.
Third, A more significant problem with session-based load balancing is that it exposes the IP addresses of the servers in the farm to the client-side browser.
What happens when a server crashes or is taken offline? Your balancing algorithm needs to account for this as soon as possible, but doing so can be problematic. If you're passing out bad IP addresses, your users will start to receive "server not available" errors.
In a round-robin DNS system, it still can take as long as 48 hours to fix the problem once you've discovered that one of your servers has crashed.
This is due to the fact that the changes to your IP address mappings need to be propagated to DNS servers throughout the Internet."
1. The time to live (TTL) on the zone files needs to be turned down severely to to reduce the time for which results are cached.
The longer the TTL, the less control there is over which IP addresses that end-users are accessing. The shorter that TTL, the greater the potential for congestion on the DNS server.
2. Users may access servers using an IP address rather than a host name.
3. Users may use non-DNS methods such as an /etc/hosts file to map server host names to IP addresses.
4. An additional problem with round-robin DNS is that the DNS daemon cannot differentiate between a request for a one-off hit, and a request that will result in many hits. That is, it is hard to control the granularity of scheduling.
5. When using round-robin DNS there is no way to assign weights to servers, all servers will theoretically receive the same number of requests, regardless of their resources and current load.