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

Steps to reproduce:

Upgrade firefox flatpak to 94

Actual results:

No DNS resolving is working anymore. (DOH is turned off, so system DNS should be used, just as with previous versions)
Also happens with a newly created user account.
System in use is Debian 11

Expected results:

Well, DNS resolved and a website shown.

The user agent above is the firefox-esr from debian I had to install to even submit this report ;)

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

Thank you for the report.
Could you submit some HTTP logs while reproducing the issue?

(In reply to Valentin Gosu [:valentin] (he/him) from comment #3)

Thank you for the report.
Could you submit some HTTP logs while reproducing the issue?
attached a try for wikipedia.org

The logs seem to be incomplete.
Could you try again and add sync to MOZ_LOG?

2021-11-08 13:23:23.369492 UTC - [Parent 2: DNS Resolver #4]: D/nsHostResolver DNS lookup thread - starting execution.
2021-11-08 13:23:23.369502 UTC - [Parent 2: DNS Resolver #4]: E/nsHostResolver DNS lookup thread - Calling getaddrinfo for host [detectportal.firefox.com].

I can see the beginning of the resolution in the logs, but they don't seem to complete.

I've just witnessed something really strange, another flatpak app (Slack) just started to not resolve DNS while the resolution of applications not installed via flatpak is working as expected.
Maybe this is a bug in a flatpak runtime? Some flatpak apps do still resolve properly while now 2 do not :/

ok, indeed.
flatpak run --share=network --devel --command=python3 org.gnome.Sdk/x86_64/41 -c 'import socket; print(socket.gethostbyname_ex("github.com"))'
does fail on my machine, while
flatpak run --share=network --devel --command=python3 org.gnome.Sdk/x86_64/40 -c 'import socket; print(socket.gethostbyname_ex("github.com"))'
resolves just fine.

Thank you for the logs and info.
Indeed, it seems all the getaddrinfo calls fail, so it looks like a OS/flatpak runtime problem.
I found this bug report for Fedora. Maybe it can help.

Also I'm curious if using DNS over HTTPS works. Try setting network.trr.uri to https://1.1.1.1/dns-query and network.trr.mode to 2
If that also fails, it could be that networking is completely down for the flatpak instance.
You could try fiddling with flatpak run --share=network org.something.App

I'm rather curious if you can find the cause for this. In any case it seems to be something specific to your system.

Missed your previous comment.
Good to know it's not caused by Firefox.
Thanks for the info.