1594150 - Change behavior of network.http.fast-fallback-to-IPv4 flag

Status: UNCONFIRMED

(Core :: Networking: DNS, defect, P3)

Description

[Revertron]

Attachment: v79FhF.png

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:72.0) Gecko/20100101 Firefox/72.0

Steps to reproduce:

I use Yggdrasil network (yggdrasil-network.github.io), which gives only IPv6 address and we have some services there. Firefox falls back to IPv4 even if the site has no IPv4 addresses in DNS (records type A).

Actual results:

Every time I open some site, that has only IPv6 IPs (only AAAA records in DNS) Firefox says "We can't connect to website mesh.ygg", here is the screenshot: https://up.zbin.eu/v79FhF.png
Firefox falls back to IPv4 for these sites, but website doesn't have A records in DNS!
This behavior is triggered because Yggdrasil searches IP in DHT network to get real routing. It takes about 1 second on first try. Every subsequent connects are going fine.
If I disable the flag network.http.fast-fallback-to-IPv4 in about:config the problem is gone.

Expected results:

Change behavior of the network.http.fast-fallback-to-IPv4 flag to not fallback to IPv4 if the site has no IPv4 IPs. Why fallback if there is no IPs to fallback to? :)

Comment 1

[Revertron]

Forgot to mention, you can use DNS servers in Yggdrasil network to test: 301:2923::53 or 301:2522::53, and a domain mesh.ygg for example.

Comment 2

[Seba S.]

Hi, Reverton!

Thanks for your contribution!

I don't have the knowledge in order to answer on this matter but I'll add product and component to keep track and to continue researching.

Please follow this bug and if you have some other information or doubts, feel free to comment.

Regards,

Comment 3

[Liam]

I have more information to add to this bug, as I found it highly replaceable during some IPv6 testing.
The example site I discovered the cause of the bug on was http://ipv6.ec2-reachability.amazonaws.com/
the AWS IPv6 reachability test. This page mixes IPv6 resources with different response times.

With network.http.fast-fallback-to-IPv4 set to true, a random set of resources from that page will fail to load, so that many of the AWS AZs are incorrectly displayed as unreachable. For example, I just enabled fast-fallback and the page told me AZs in Cape Town, Hong Kong, Mumbai, Osaka, Seoul, Tokyo, Fankfurt, Ireland, London, Milan, Paris, Stockholm, Bahrain, Sao Paulo, Beijing and Ningxia were unreachable. On the reachable list were North Virginia, Ohio, North California, Oregon, Los Angeles, Singapore, Sydney, Canada, and the US "AWS GovCloud"

With network.http.fast-fallback-to-IPv4 set to false, all resources load and All AWS AZs are correctly displayed as reachable.
A packet trace shows that when fast-fallback is true, firefox is only making DNS queries for the A records, and not the AAAA record of the failed resources (these resources have no A record), and it is notable that locations with a higher RTT are more likely to fail.

I have also discovered the same problem occurs on mobile, and is the reason accessing my mobile providers IPv6-only, internally hosted account management pages fail randomly on firefox (while chrome is fine). Previously is was possible to use the page by disabling the fast-fallback flag, however about:config no longer works on firefox mobile.

Comment 4

[Liam]

*replicable

Comment 5

[Liam]

Attachment: fast_fallbak_on_3.png

AWS reachablilty test with fast fallback enabled

Comment 6

[Liam]

Attachment: fast_fallback_off.png

The same test, with fast fallback disabled