Using multiple A-records for my domain - do web browsers ever try more than one?
If I add multiple A-records for my domain, they are returned in a round robin order by DNS servers.
192.0.2.1 A example.com 192.0.2.2 A example.com 192.0.2.3 A example.com
But how does web browsers react if the first host (
192.0.2.1) is down (unreachable)? Do they try the second host (
192.0.2.2) or do they return a error message to the user? Are there any difference between the most popular browsers?
If I implement my own application, I can implement so that the second is used in case the first is down, so it's possible. And this would be very helpful to create a fault tolerant website.
Yes, most browsers from the last 5-10 years will try the other A records if one fails to respond. This is sometimes called "browser retry" or "client retry" apparently. You'll pretty much only find stuff about it in the context of the various browser exploits which this feature enables against sites not using it (see DNS rebinding and DNS pinning, anti-dns pinning, anti-anti-dns pinning, anti-anti-anti-dns pinning, and so on). Kind of a bad reputation, but it does prove it exists.
Pretty much every browser does indeed receive the full list of A records, and does indeed check others if the one it is using fails. You can expect each client to have a 30 second wait when they first try to access a site when a server is down, until it connects to a working address. The browser will then cache which address is working and continue using that one for future requests unless it also fails, then it will have to search through the list again. So 30 second wait on first request, fine thereafter.
But it isn't something you necessarily want to use, it's going to have lots of caveats about browser compatibility, os compatibility, proxy compatibility, cache-control headers are going to have weird effects on whether it remembers which IPs are down or starts having that 30 second wait on every request, people writing custom clients for your site are going to end up using gethostbyname instead of getaddrinfo and not be able to handle the failover, all sorts of potential problems.
You also can't rely on multiple A records to allow for "master" and "slave" servers, because you'll never know which address a browser is going to pick out of the list. They all need to be just as capable of handling visitors if running, because any one might get traffic if it's up. A browser might think your third server out of the list is the most appealing, maybe it looks the closest, and it will choose that one even though all three are still up.
But if you can live with the limitations and have a reasonably simple HTTP system that you can predict the browser interaction with, it will work.
Oh, you'll also have to deal with a lot of people telling you this doesn't exist (since that was true 15 years ago). But you can try telnet-ing to a domain name with several A records, some with dead IPs and some good ones, if you need to prove it (yes, even good old telnet now uses getaddrinfo and handles multiple A records gracefully these days) -- it will print out a nice list of the IPs it's trying until it finally succeeds.
Here's a report from the National Bureau of Economic Research which supports Joff's answer.
Intriguingly, while stackexchange.com points to one IP, Google returns several: $ dig google.com @ns1.google.com ;; ANSWER SECTION: google.com. 300 IN A 188.8.131.52 google.com. 300 IN A 184.108.40.206 google.com. 300 IN A 220.127.116.11 google.com. 300 IN A 18.104.22.168 google.com. 300 IN A 22.214.171.124 google.com. 300 IN A 126.96.36.199 google.com. 300 IN A 188.8.131.52 google.com. 300 IN A 184.108.40.206 google.com. 300 IN A 220.127.116.11 google.com. 300 IN A 18.104.22.168 google.com. 300 IN A 22.214.171.124
Sorry, but I don't think that's how it works. Browsers have nothing to do with resolving IP addresses -- that happens in system software. If you provide multiple A records, you should assume that any given client will receive a random one from the list.
This *is* how it works in contemporary browsers. They all choose to use system calls like getaddrinfo() to get multiple IP addresses and handle failover internally, rather than getting a single IP address from the system. Other commenters and answerers here are part of the "lot of people telling you this doesn't exist" from Joff's last paragraph---I assume they mean well but they are spreading misinformation.
To support Joff's statement of "browsers 5-10 years ago", here's a test done by the National Bureau of Economic Research which states you get this kind of system working up to IE 8. Sound fair to me. :)
"Browsers have nothing to do with resolving IP addresses " on the contrary, lately they more and more have something to do with resolving, with DNS over HTTPS now the whole resolution happens (can happen) in the browser irrespective to the OS. See Mozille latest attempts to force DOH to CloudFlare over all Firefox users.
Be warned that Windows Vista implements the stupid parts of RFC3484 (i.e. the backporting from IPV6 to IPV4) and will prefer the IP address that shares most prefix bits with the user's IP address rather than picking one at random. Since most users have IP addresses that start with 192.168, that means whichever of your IP addresses happens to share most prefix bits with that will get most of the Vista traffic. Microsoft fixed this particular bit of idiocy in Windows 7 and later, so it's not as much of an issue as it used to be.
This is basic DNS load balancing distribution technique: DNS Round Robin. This has nothing to do with browser, it depends on the implementation of the resolver , and the local/remote cache of the DNS address. Changes are that if a server fail, due to caching in the DNS layer your website may be inaccessible.
See here for a basic explanation about Round Robin DNS on WikiPedia.
Well, since the browser is the resolver - it depends on the implementation of the browser, as what I know.
No, there are the system library that resolve the dns using of course the DNS Nameserver that you setup in the system. The function are part of the standard operating system library.
But both `nslookup cnn.com` on Windows and `host cnn.com` on Linux returns a **list** of IP-addresses, so then it definitely depends on the implementation of the **browser**.
They return a list because that is what is resolved from the dns server. The OS determines what IP to use, not the browser. Windows will use whichever resolved first. *ix implementations depend partially on the bundled tcp stack implementation.
@iivel: No, that is not true. If I write a Java program and resolve a name with InetAddress.getAllByName("example.com") I get a list with all IP-addresses, so I can choose to start a TCP-connection to all of them if I want. And it's the same if you use getaddrinfo() in C. So it's definitely a choice that the developers do and **not** the Operating System.
DNS load balancing only describes a method in which it changes the order of the results - however - the client still needs to know what to do as per the WikiPedia page "Usually, basic IP clients attempt connections with the first address returned from a DNS query so that on different connection attempts clients would receive service from different providers, thus distributing the overall load among servers.".
@iivel/@Jonas You can choose to use the system implementation, a language implementation (which in turn may use the system implementation), or create your own; just like anything else in software development. That is why when doing DNS lookups you need to ask yourself how the lookup works exactly. Does it first check filesystem files like /etc/hosts? Does it maintain its own cache? Which record types are supported? How are multiple values handled? The answer to all of those questions is **it depends on the implementation**.
@J.Money This question is asking exactly about the implementation, *not* how we *can* do it.
The OS determines what IP to use, not the browser. Windows will round robin the returned list (in the list passed back from DNS), though will continue to use the same address until DNS is flushed or times out. *ix implementations depend partially on the bundled tcp stack implementation but typically follow a round robin method as well.
No, this is wrong. If I write a Java program and resolve a name with `InetAddress.getAllByName("example.com")` I get a list with all IP-addresses, so I can choose to start a TCP-connection to all of them if I want. And it's the same if you use `getaddrinfo()` in C. So it's definitely a choice that the developers do and not the Operating System. The DNS-server only decides in what order the list of IP-addresses is returned.
Ok, so you can manually do whatever you want with the stack - you could even roll your own and forget about winsock all together. However, if you write an app and let the OS do its thing (abstract away) - then the behavior is as noted. You question was specifically about traditional application behavior - not what is possible. Most developers handle using the unresolved name and let the OS do what it does, rather than tightly coupling behaviors together.
Not sure why the answer was downvoted, but the question is about what browsers do. Currently all browsers let the OS do the resolution (short of some plugins for Firefox and Chrome). If you'd like details on how to ensure availability should a provider go down - look at load balancers or clustering.
Browsers probably do as you say - let the OS do the DNS lookup, but it return a **list** with IP-addresses to the Browser. And the question is: What does the most popular browsers do if the first address is unreachable? do they try the second?
In theory they will (if they are on XP SP2 or greater for IE). I know that FF does, I'm not sure about Chrome. This is a decent breakdown on the mechanism for you. http://www.tenereillo.com/BrowserDNSCache.htm If high availabilty is important - I wouldn't leave it to browser behavior though (yes to multiple A records, but no to different systems)
What do you mean with "This is a decent breakdown on the mechanism for you"? It looks like the browsers do try to connect to the second host, which is what I wanted. And the article you linked to also said that multiple A records are a great solution.
The OP asked what a browser will do if one server is down. If you have multiple A records you wouldn't notice anything in the browser but maybe a slight delay. Hardly any, same reason we use multiple name servers for redundancy. What operating systems do, and what you can do pragmatically are two different things. Anyone remember dialup services when you had to manually configure name servers? If you didn't you connected to the net and your browsers didn't load any sites but you could still ping them, because no name servers were configured. That's the OS handling DNS.
The article you quoted by Pete Tenereillo is known to be outdated (mostly incorrect nowadays). With Chrome, chrome://net-internals/#dns shows current DNS cache. I don't believe OS always determines which IP to use. At least with Chrome you can choose to use AAAA if available or A only. OP is talking about how browsers select from DNS relies, not how the computer find its DNS server....