20

How do most browsers behave if they get multiple A-records from the DNS server? Do the stick to one IP as long as it is reachable (and only use another if the IP is down)? Or do they switch all the time for no reason?

If the majority current browsers stick to one IP, DNS-RR would be enough for me as a simple failover solution.

HiPerFreak
  • 201
  • 1
  • 2
  • 3
  • 1
    I can't answer your question directly, but I will point out to you that you have to deal with caching at both the browser and the OS level! Have fun :) – SpacemanSpiff Jan 14 '12 at 20:35
  • 1
    http://webmasters.stackexchange.com/questions/10927/using-multiple-a-records-for-my-domain-do-web-browsers-ever-try-more-than-one – user9517 Jan 14 '12 at 20:37
  • 1
    @Iain - Awesome link – SpacemanSpiff Jan 14 '12 at 21:15
  • How many machines do you have for a backend? If 2 machines with active-passive is okay, get a third IP address, and use heartbeat to failover it between physical machines. Alternatively, I think ultramonkey supports assigning to backends based on source IP, which is *almost* the same as a single client. You could probably also hack something together by having each backend set a unique cookie, and having a frontend web server proxy to backends depending on the cookie. (Apache's mod_rewrite can probably do it.) – jon Jan 15 '12 at 22:07
  • There is no single rule covering all browsers, so at the very least you need to specify which one/ones you're interested in. – John Gardeniers Jan 16 '12 at 22:26

6 Answers6

14

Each browser has it's own method of handling round-robin DNS, I've spent some time today researching this problem and will continue to update my answer as I find proof of implementation which will limit my answers to browsers that expose their behavior.

Google Chrome

Google Chrome (v58 used) will request all host entries for an address (A, AAAA, CNAME) and put them into an array (address_list). Chrome will then attempt to open a socket on each IP address in order from first to last, chrome will not attempt the fastest or closest IP, it assumes the first IP (given by your upstream dns resolvers) is the best IP. In my tests bind and windows dns servers give a different order of IPs per lookup, giving what seems like 50/50 split in bandwidth to each IP. This functionality is exposed in chrome://net-internals/#events&q=type:SOCKET%20is:active

Curl (libcurl/7.54.0)

Curl also has this fail-over function but the --connect-timeout is much longer than the default in chrome, chrome fails over immediately, Curl does not. If you use libcurl and want to survive a round-robin dns instance where one IP fails, (works in chrome but not in code) be sure to specify this value lower.

DEFAULT_CONNECT_TIMEOUT:0 made me think this wasn't possible with curl.

* After 149990ms connect time, move on!

On both browsers, the IP was not sticky, they followed the TTL given in DNS and once that ttl expired (chrome maintains this internally, curl asks on each request), the ip selection is performed each time as described above.

What does this mean? DNS-RR is ok for some systems, but it is not designed for failover. You should expect that all results from the DNS looking are (a source of truth) valid and available to serve traffic. There are many ways to ensure IP availability, such as virtual float IPs, BGP/Routing tricks, etc. Use them.

All tests performed in IPv4 only environment, will return with dual-stack results once enough infrastructure is available to test.

I speculate these changes are a side-effect of the IPv6-Fallback RFC Happy Eyeballs

Update A useful consideration, RR DNS can only assist with load balancing, not application failures, if one of your nodes has a 503 you will serve 40-60% if your traffic 503s. The assumption is made that all IPs listed are valid working endpoints if reachable

Jacob Evans
  • 7,636
  • 3
  • 25
  • 55
4

All modern browsers implement this https://www.rfc-editor.org/rfc/rfc8305 Happy Eyeballs Version 2: Better Connectivity Using Concurrency

Roughly that means that a server with fastest connection will be used. IPv6 has higher priority.

Community
  • 1
user602895
  • 41
  • 1
  • This is the best answer I have found so far, especially as it provides a reference to applicable RFC. I was able to further find this Wiki article, which says that major browsers are supporting the Happy Eyeballs for a long time already: https://en.wikipedia.org/wiki/Happy_Eyeballs – GoodMirek Dec 13 '20 at 21:36
  • 3
    AS of December 2020. YES, HE v1 was implemented long ago BUT I was writing about HE v2 wich was approved in December 2017. One year ago in the end of 2019 HE v2 wasn't implemented in Chrome. But now it works. HE v2 means that a server IP with the nearest ping will be chosen for connection. If IP is down next server will be tried. Under IP I mean IPv6 and IPv4 with IPv6 priority. I made some experiments and I can confirm that at least modern Chrome, Firefox and Opera always choose a server with nearest ping. In the end of 2019 Chrome chose random IP address – user602895 Dec 15 '20 at 05:52
  • @user602895 for the best ping do browsers are probing all DNS-returned IPs one by one? – Dmitry Sychov Aug 21 '21 at 11:45
4

See this my question (and answer): How browsers handle multiple IPs.

Shortly - round robin dns does not improve availability at all. Browser chooses one IP and sticks to it, even if it does not responds. (Checked with FF and chrome).

Once browser dns cache expires, hostname resolved again and the process repeated, regardless of did IP answered or not.

For basic HA, you may use dynamic DNS or various IP-based approaches.

EDIT: This behavior will take place when inaccessible host acts as a "black hole". If instead the host ctively refuses incoming connections, browser will try one ip, get refuse and immediately use another ip and thus it will fail-over pretty well.

Community
  • 1
Sandman4
  • 4,045
  • 2
  • 20
  • 27
  • 3
    Maybe this changed in the recent years, but I can confirm that upon multiple refreshes in Firefox, the IP does in fact change, although not too often. Possibly this answer is out-dated? – Yeti Aug 30 '16 at 08:29
  • My research (from 2015) is that Chrome, Firefox and MSIE DO NOT behave as Sandman4 describes. MSIE is notably different in that it requires a full TCP timeout before attempting a connection to the next address listed if the first fails. – symcbean Jan 22 '18 at 17:34
2

edit: Editing my answer since HiPerFreak schooled me.

DNS servers will return a list of all A records it has for a given host name. Where round robin comes in is that it rotates how the list is ordered. The link that lain posted is a great example of how web browsers will make use of that list.

Round Robinning can be used for a very primitive form of load balancing, but is a very poor substitute for real load balancing, since if one of the hosts in the round robin rotation goes down, the DNS server will be none the wiser and will still put the IP address of the downed node in the list.

Ryan Ries
  • 55,011
  • 9
  • 138
  • 197
  • The DNS server always hands out ALL addresses. The browser is the one, who decides which one gets used (as discuseed many times here and elsewhere). Also, the OS passes all IPs to the browser. – HiPerFreak Jan 14 '12 at 21:12
  • 2
    @HiPerFreak The often-seen configuration (especially for a large number of A-Records) is that the DNS hands out *some* addresses (although not all, usually to make sure they fit into a UDP packet of 512 bytes and not incur unnecessary overhead), usually in a changing order. – the-wabbit Jan 14 '12 at 21:20
  • I was thinking of 2 or 3 IPs. – HiPerFreak Jan 14 '12 at 21:35
  • @HiPerFreak: I just wanted to say that you are right in that a DNS server does hand out all the A records when queried for a name if multiple A records exist for that name. I have a DNS server and just did a packet capture with Wireshark while I pinged the hostname to confirm. Thank you -- I learned something today! :) – Ryan Ries Jan 14 '12 at 22:04
0

They switch the IPs, it isn't a failover solution.

The browsers let the OS to do the name resolution, and for examle Linux always randomizes the IP addresses, try host google.com several times. The IPs will come in random order.

Stone
  • 6,941
  • 1
  • 19
  • 33
  • Why do they do this randomly and without reason? Wouldn't it make sense to reuse a know-to-work IP as long it is up-and-running? – HiPerFreak Jan 14 '12 at 20:49
  • 1
    It is for load balancing. – Stone Jan 14 '12 at 20:52
  • @HiPerFreak See also: http://en.wikipedia.org/wiki/Round-robin_DNS – voretaq7 Jan 14 '12 at 21:06
  • @HiPerFreak: THe reason it doesn't stick to a known-to-work IP is that the name resolution knows nothing about whether that IP works now or has in the past. The browser doesn't stick to a single IP, because the name resolution is telling it to use different IPs. :-) – Sean Reifschneider Jan 15 '12 at 03:22
  • @Sean: As discussed in the blow answer, the name resolution gives the browser ALL IPs and the browser decides, which one to use. And the browser knows which IPs did work and which not. So this cannot be the reason. – HiPerFreak Jan 15 '12 at 07:40
  • The order randomization actually happens on the DNS server, not on the client. – jon Jan 15 '12 at 21:43
  • @SeanReifschneider,HiPerFreak: depends on how smart the browser tries to be. – jon Jan 15 '12 at 21:45
  • @HiPerFreak: The browser gets an *ORDERED* list, the ordering of which has no knowledge of whether previous connections worked. As I said, the DNS server is publishing that is wishes you to round-robin the requests, so why should the browser break this? – Sean Reifschneider Jan 16 '12 at 08:40
  • -1: yes it does provide for failover in most browsers - see http://serverfault.com/questions/424785/if-dns-failover-is-not-recommended-what-is `and for examle Linux...` - What exactly does the kernel have to do with this? The DNS server is not linux, the (client) resolver is not Linux. – symcbean Sep 10 '12 at 12:35
0

The DNS return all the IP in a list but they change the order of the list and this order is not random or change when 1 fails but they always return the IPs in the same sequence for load balancing reasons. When the browser receive the list, I suppose it picks the 1st in the list if not known as non-working.

laurent
  • 2,035
  • 16
  • 13