0

I hve read a bunch of the answers here and most of them are dealing with round-robin DNS (RR DNS), but I have a different question. If at the DNS level I am resolving to say 3 IPs in a specific order, .1/.2/.3 will the browser use these addresses in order?
If there is an error on one of the IPs, 404, 503, 403, whatever, will the browser try the next IP in order, such that if server .1 throws a 503 error, will the browser then try .2? and .3 and so forth until it is able to reach a working system or run through all off the addresses?

The intention here is not to round robin the traffic or potentially spread load, I am contemplating that if I have an app go down, will the browser auto recover. Additionally, let's assume the first 2 entries are a local center and the 3rd is a less desirable choice, could I count in the order so I am not sending a user to a terrible latency decision, because I wanted it in the resolution as a final resort back up.

Thoughts?

jroza1
  • 1
  • There is no order in the DNS (outside of some specific record types that encode an order). You get sets of records, not lists. If a name has multiple `A` or `AAAA` records they will be typically returned in a random order changing at each query. – Patrick Mevzek Mar 19 '19 at 15:26
  • DNS, alone, is not a good solution for a round-robin mechanism. At least it gives full observed and final behaviour solely under the control of the client application. Do you control and manage all possible clients for your service? If not, you have no guarantee on how they will handle multiple records and what they happen in case of failures with one. – Patrick Mevzek Mar 19 '19 at 15:27
  • there are ways to order responses with smarter DNS systems, but we will set that aside for a moment. So, basically for this to be successful, the browser would need to receive a timeout before it would go to the next IP in the resolution record, is that correct? So we we handed back an error, the Brows would see the IP as basically valid even though there is an error. If there is a timeout it would tigger the browser to go to the next? – jroza1 Mar 19 '19 at 15:31
  • "there are ways to order responses with smarter DNS systems" that is not the problem. Even bind can force the order. But the protocol clearly specifies records as "sets" not as "lists". So applications can have no guarantee to get records in a specific order (even if you configure one nameserver to return a specific order, maybe the external secondary you use is configured differently, or maybe the resolvers will shuffle the records, etc.). – Patrick Mevzek Mar 19 '19 at 17:59
  • "the browser would need to receive a timeout before it would go to the next IP in the resolution record, is that correct?" yes, if connection to one IP fails, **typically** (no guarantee in the protocol at all) **HTTP browsers** (and not necessarily other applications, nor all HTTP browsers in fact) will try the "next" one. Until one succeeds. Or none. But if the connection to one fails it means no HTTP exchange and hence no HTTP return codes such as `404`, `503`, `403` or whatever you said in your post. – Patrick Mevzek Mar 19 '19 at 18:01
  • You have the same problem about the dual stack and IPv4/IPv6 records. Have a look at the document about the "Happy eye-ball algorithm" to see a solution on how systems can favor IPv6 addresses while still defaulting back to IPv4 if needed, without extended timeouts or serial exploration of all IP addresses. – Patrick Mevzek Mar 19 '19 at 18:03

2 Answers2

1

First, DNS records are not returned in a predictable order. The one that the client uses, if any, is almost always only the first one. But because the order they are returned is essentially random, that could be any of them.

The browser doesn't care about any of this. It is going to try once to connect to one of the servers and will not try another (except for Happy Eyeballs, which is mostly not relevant here). Once it receives a response, any response, then it's done. It does not 'try again" on its own.

Whatever solution you design, it is important that you remove malfunctioning backends as soon as possible so that traffic no longer goes to them. This is one of the purposes of a load balancer.

Michael Hampton
  • 244,070
  • 43
  • 506
  • 972
  • I thought browsers had some recovery function built in where if there is a timeout of like 10 or 20 seconds it would look at the next IP that was handed back. If having multiple IPs in a resolution was useless, why would we do it? – jroza1 Mar 19 '19 at 15:35
  • Jroza-maniac:~ jroza$ nslookup www.plusbyme.com Non-authoritative answer: www.plusbyme.com canonical name = plusbyme-com.zenedge.net. orcle-demo.b.waas.oci.orclecloud.net canonical name = oci.tm.u.waas.oci.orclecloud.net. oci.tm.u.waas.oci.orclecloud.net canonical name = us-losangelessc.u.waas.oci.orclecloud.net. Name: us-losangelessc.u.waas.oci.orclecloud.net Address: 152.70.44.11 Name: us-losangelessc.u.waas.oci.orclecloud.net Address: 152.70.44.81 Name: us-losangelessc.u.waas.oci.orclecloud.net Address: 152.70.44.52 – jroza1 Mar 19 '19 at 15:36
1

There is a principle you must know;

If the client receive an error 403, 404 or 503, that mean the remote server sent the error code back, the client will not try a second IP, as it's actually getting data there. Those error mean a webserver error, not a internet link error.

The client will only switch IP after the TTL of the DNS entry, or if the application request a new DNS lookup, to cache a new entry. (or if the client restart the app, and thus a new DNS lookup might happen)

yagmoth555
  • 16,758
  • 4
  • 29
  • 50
  • Makes sense.... this is what I was thinking. So really, if there is a timeout, it will move on in the list, if there is any response, the browser will honor the IP and the response rather than moving to the next IP address. Makes sense. – jroza1 Mar 19 '19 at 15:37