DNS over HTTPS oddities: fallback, TRR mode
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.
Chosen solution
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.
Read this answer in context 👍 0All Replies (6)
You can check this with DNS Lookup tool on the about:networking page.
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.
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.
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.
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
Chosen Solution
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.