does firefox failover on DNS Round Robin?

[Klaus Mueller]

Hi,

I realised that browsers do failover on alternative entries on DNS Round
Robin. Also others noticed this, but [have found it very hard to get
clear confirmation that they are supposed to.][article]

So I set up this setting myself http://dns-no-tcp.klml.org/ and this
works with all my browsers.

wget even shows me, it is also doing the failover

wget http://dns-no-tcp.klml.org/
--2018-10-30 11:57:00--  http://dns-no-tcp.klml.org/
Resolving dns-no-tcp.klml.org (dns-no-tcp.klml.org)... 188.106.110.128,
95.143.172.147
Connecting to dns-no-tcp.klml.org
(dns-no-tcp.klml.org)|188.106.110.128|:80... failed: No route to host.
Connecting to dns-no-tcp.klml.org
(dns-no-tcp.klml.org)|95.143.172.147|:80... connected.
HTTP request sent, awaiting response... 200 OK
....


Of course DNS round robin has no handling of server failures. But it is
a common notion, that clients also do no failover.

[If a service at one of the addresses in the list fails, the DNS will
continue to hand out that address and clients will still attempt to
reach the inoperable
service.](https://en.wikipedia.org/wiki/Round-robin_DNS)

But for me it seems, at least browsers, wget and curl do.


So my queston is: is this behavior a firefox feature? Is there some
documentation, standard or RFC?



thank you very much
Klaus


[article]:
https://blog.engelke.com/2011/06/07/web-resilience-with-round-robin-dns/

--
Klaus Mueller

[Daniel Stenberg]

On Thu, 1 Nov 2018, Klaus Mueller wrote:

> I realised that browsers do failover on alternative entries on DNS Round
> Robin. Also others noticed this, but [have found it very hard to get clear
> confirmation that they are supposed to.][article]

This is how Internet clients in general is supposed to work since the dawn of
time really.

You ask for all the addresses of a host, then iterate over them and if one
fails, you continue to the next. Ideally you try IPv4 and IPv6 addresses in
parallel, so called happy eyeballs, and stick to the one that connects first.

Note also that getaddrinfo() doesn't typically return the addresses in a
random order so this list of adddresses is often not as "round robin" as you'd
think. [1]

> So my queston is: is this behavior a firefox feature?

Firefox works this way too, yes, and it does happy eyeballs.

> Is there some documentation, standard or RFC?

Already RFC 1034/1035 (November 1987) recommends/discusses returning multiple
records for a name. I don't think trying all/several addresses is mandated by
any standard, but why wouldn't a client try the next if the first one fails?

I'm pretty sure I first learnt to do this reading Steven's network books in
the 90s.

[1] =
https://daniel.haxx.se/blog/2012/01/03/getaddrinfo-with-round-robin-dns-and-happy-eyeballs/

--

/ daniel.haxx.se

[ddamj...@mozilla.com]

There are some RFCs about Happy-Eyeballs: RFC 8305 which obsoletes RFC 6555.

[Daniel Stenberg]

On Fri, 2 Nov 2018, ddamj...@mozilla.com wrote:

> There are some RFCs about Happy-Eyeballs: RFC 8305 which obsoletes RFC 6555.

Firefox doesn't really implement RFC 8305 though, which specifically says:

"Implementations SHOULD NOT wait for both families of answers to return
before attempting connection establishment"

... which thus rules out using a single getaddrinfo() to get both A and AAAA
records.

When doing DNS-over-HTTPS instead, Firefox will at least do the different
resolves separately and *can* act as soon as the first response comes back.
(But will only do so by default if the A entries return first, for practical
reasons.)

Firefox's Happy-Eyeballs is more in the RFC 6555 style.

--

/ daniel.haxx.se