DNS round robin with hosts file and browsers on windows

I've been playing around with the following scenario and I'm wondering if this should work in theory:

Configure the following in the hosts file on windows:

<IP of server that's down>     hostA
<IP of server that's down>     hostA
<valid    IP>     hostA

and then access http://hostA:8080 in Chrome, FF and IE. My hope is that all three browsers will eventually find the hostA mapping to the valid IP.

Right now I'm testing with IE and I'm seeing some odd results where it sometimes seems to work and sometimes it doesn't. I wanted to check to set if this configuration and the result I'm expecting are valid.
Who is Participating?

Improve company productivity with a Business Account.Sign Up

opikeConnect With a Mentor Author Commented:
Giltjr states: "Most web browsers try the 1st IP address returned in a list and stop there. "

That is not what the article states.

I quote:
"You’d have your program ask the network API for all of the IP addresses associated with a name, and then your program can try them one at a time until it gets something to connect...
<some text omitted>
As it happens, it appears that they (browsers) all do work that way"

My testing confirmed that browsers do in fact behave this way.

Also, I'm not looking for load balancing, just fail over. For our current needs, the fail over capability now built into the all modern, popular browsers, is sufficient.
I have to ask: what's your ultimate goal?  There may be a better way to accomplish it than by messing around with hosts files (which is almost never the best way to accomplish anything, in my opinion).
All 3 IP addresses are "valid."  Just because a host, or a service on a host, may be down, does not mean the IP address is invalid.  It just means that you will not get a response.

If you are hoping that a browser will try each IP address returned until it finds one that responds, you are out of luck.  Browsers will use the 1st IP address returned and that's it.
What Kind of Coding Program is Right for You?

There are many ways to learn to code these days. From coding bootcamps like Flatiron School to online courses to totally free beginner resources. The best way to learn to code depends on many factors, but the most important one is you. See what course is best for you.

Bruno PACIIT ConsultantCommented:

As giltjr explained round robin is not a high availability solution, it's only a load balancing solution. DNS will load balance requests because of round robin but is not in charge to check availability of services "behind" IP addresses.
So DNS gives you an IP even if the server or services associated to this IP are down.

Applications may be smart enough to check all IPs in the list obtained from DNS until they find an "alive" one... But browsers are not that smart: they ask for an IP, and if this one is "bad" they fail....
opikeAuthor Commented:
My ultimate goal is to test the server retry capabilities of the main browsers, which it turns out, all three main browsers (FF, Chrome, IE) possess. This configuration wasn't meant to be a permanent set up, I just wanted to see how the browsers would be have when one of the IPs configured to a host was not available. This blog post covers the high-availability of browsers in more depth:

So you were trying to do a test to prove that testing another person did was right?

O.K., I can live with that.  However what the article says is right.  Most web browsers try the 1st IP address returned in a list and stop there.  In fact most IP based products stop after the 1st address.  Just easier for developers to write code that gets one thing, tries, and fails.

As PaciB stated, round robin DNS was a crude attempt at load balancing.  Was never meant to be used for fail over recovery.
I'll admit, this functionality is news to me, but if it works, more power to you.  However, if this is for anything but a very small number of users, you'll want to implement it on your DNS server rather than clients' hosts files for ease of administration.  Of course, that means you may get inconsistent results due to client-side caching...

You mentioned that you're seeing some odd results during testing.  Have you used a packet sniffer to see what addresses the test machine is trying to contact?
Misread his results.

This is news to me too.  I will have to do some testing as what he shows as his results have not been what I have experienced.
opikeAuthor Commented:
Completed testing and confirmed the results of the article on my own.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.