搜尋 Mozilla 技術支援網站

防止技術支援詐騙。我們絕對不會要求您撥打電話或發送簡訊,或是提供個人資訊。請用「回報濫用」功能回報可疑的行為。

Learn More

DNS over HTTPS oddities: fallback, TRR mode

more options

After a recent change of my website's name registrar, Firefox (both on Linux and Android) has been running into issues finding the server/address. I suspect this has something to do with DNS, whether it be DNS over HTTPS (DoH) or otherwise.

Specifically, this seems to happen when DoH is on (as shown by about:preferences#privacy). I have confirmed that `curl --doh-url <cloudflare DNS query> <my website>` also fails to resolve the request.

This leaves me with a few outstanding questions:

  • Do I have any control of whether the DoH request fails? Is this something I can fix through my host or name registrar?
  • The TRR mode shown in about:preferences#privacy appears to be different than the one shown in about:config (2 versus 0, respectively).
  • Shouldn't Firefox be falling back to normal DNS? I have confirmed via `curl` that my website works fine over https.

Firefox and curl results for Linux confirmed on two machines on the same network.

After a recent change of my website's name registrar, Firefox (both on Linux and Android) has been running into issues finding the server/address. I suspect this has something to do with DNS, whether it be DNS over HTTPS (DoH) or otherwise. Specifically, this seems to happen when DoH is on (as shown by about:preferences#privacy). I have confirmed that `curl --doh-url <cloudflare DNS query> <my website>` also fails to resolve the request. This leaves me with a few outstanding questions: * Do I have any control of whether the DoH request fails? Is this something I can fix through my host or name registrar? * The TRR mode shown in about:preferences#privacy appears to be different than the one shown in about:config (2 versus 0, respectively). * Shouldn't Firefox be falling back to normal DNS? I have confirmed via `curl` that my website works fine over https. Firefox and curl results for Linux confirmed on two machines on the same network.

被選擇的解決方法

Thanks for the help and information here. It turns out the root cause was DNS issues, specifically migration of a DNSSEC domain to a name registrar who did not support DNSSEC on their nameservers.

從原來的回覆中察看解決方案 👍 0

所有回覆 (6)

more options

You can check this with DNS Lookup tool on the about:networking page.

more options

Thanks, I forgot to include that. I get NS_ERROR_UNKNOWN_HOST.

It's still not clear what the answers to my three points above are though. If it's not using DoH (TRR mode 0), it should just use normal DNS, in which case everything should be fine if curl is to be trusted. If it is using DoH (TRR mode 2), the query will fail as curl confirms, but it should fall back to a working DNS query.

more options

There probably is some technical documentation on this, but to ruminate a bit...

With "Increased Protection" or network.trr.mode=2, the documentation says

We will only switch to a backup option if there are any issues with your chosen provider. See: Configure DNS over HTTPS protection levels in Firefox

Does this mean something different than what this mode did before? The older article said:

... DoH is enabled for users in “fallback” mode. For example, if the domain name lookups that are using DoH fail for some reason, Firefox will fall back and use the default DNS configured by the operating system (OS) instead of displaying an error. See: Firefox DNS-over-HTTPS

I don't know whether "issues" or "fail for some reason" means the host was not found by the trusted resolver, or that Firefox can't get a valid response from the trusted resolver. It could be a privacy problem to "leak" every typo'd host name to the local resolver.

more options

Thank you for the clarification. These things still seem a bit loosely defined, but I think you may be right about "issues" covering more low level problems rather than the success of the resolution.

Two further issues/questions:

  • it seems that on first startup of Firefox there is an inconsistency between network.trr.mode and the "GUI" setting in about#preferences, with the setting being "default" and mode 0, it says status active. However, if I change to increased protection (mode 2) and then back to default, it now says status off. All this is in the GUI, just checking about:config to see what's happening.
  • Does Cloudflare (my DoH provider) have it's own DNS servers that perhaps my new registrar's info has not yet propagated to, or does it just forward my encrypted query to an actual DNS server? If it's the former, this could explain the behavior I'm seeing.
more options

gabriel.h.brown said

with the setting being "default" and mode 0, it says status active.

There is another setting doh-rollout.mode which takes precedence in "Default" mode. This only appears for certain regions where it is being default enabled and has the same mode values as network.trr.mode.

TRR-first (mode 2) is not strict by default (network.trr.strict_native_fallback) and will readily fallback on lookup failures and 1.5 second timeouts. A fallback reason is recorded which you can see at about:telemetry#search=TRR_SKIP_REASON.

https://firefox-source-docs.mozilla.org/networking/dns/dns-over-https-trr.html

more options

選擇的解決方法

Thanks for the help and information here. It turns out the root cause was DNS issues, specifically migration of a DNSSEC domain to a name registrar who did not support DNSSEC on their nameservers.