User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:103.0) Gecko/20100101 Firefox/103.0

Steps to reproduce:

This bug has been around for 2 year at least and I know at least one other person on a different Linux distro who has observed it. Neither of us knows a reliable way to reproduce it other than using Firefox for a long time while changing connections supporting and not supporting IPv6.

Restarting the browser always fixes the problem, so does connecting over an IPv6 capable proxy. Neither of toggling IPv6 support in Firefox, toggling DoH in Firefox or clearing Firefox's DNS cache helps. Waiting helps, but it takes unpredictably from half an hour to several (even 10 or so) hours.

I do not use DoH in Firefox (I do however use resolved with DoT servers).

How to actually reproduce?

1. Be (un)lucky (as a wrote, it occurs rarely)
2. Change network connection from IPv6 capable to IPv6 incapable
3. Visit almost any site by domain (does not matter whether dual-stack or IPv4 only)

Visiting a website by directly entering an IPv4 address works.

Visiting a website by directly entering an IPv6 address or a domain name that resolves to an IPv6 address, that is somehow reachable (I use IPv6 only VPN for internal services) works. Toggling the VPN connection does not help. It does not provide a default IPv6 route anyway.

All other programs work, Chrome, curl, mutt, resolvectl query, even separate Firefox instance (run in a namespace using firejail), as well as Firefox after restart.

In the broken state, about:networking#dnslookuptool returns IPv6 addresses only. about:networking#dns shows only IPv6 addresses (described as ipv4 however).

Actual results:

Got "Unable to connect"

Expected results:

This site should have loaded.

The Bugbug bot thinks this bug should belong to the 'Core::Networking' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

We may have a problem with falling back to IPv4. The capability is implemented and I do not know why it is not working.

It would be very helpful for us if you could create a HTTP log when that happens.

See the HTTP Logging page for steps to capture HTTP logs.

If the logs are large you can create a zip archive and attach them to the bug. If the archive is still too large to attach, you can upload it to a file storage service such as Google drive or OneDrive and submit the public link.

Logs may include personal information such as cookies. Try using a fresh Firefox profile to capture the logs. If that is not possible, you can also put them in a password protected archive, or send them directly via email to necko@mozilla.com

No response from reporter. If you are still seeing this, please reopen and attach some logs. Thanks!