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

Steps to reproduce:

Enabled DNS of HTTPS in Network Settings Menu. Disconnected Access Point from Internet. Modified local DNS to respond to bank host name.

Actual results:

Firefox used local, poisoned DNS for bank hostname lookup

Expected results:

Firefox should have at least warned the user that Cloudflare DNS can not be contacted and DNS lookups are not secure instead of silently reverting to using the local DNS for all lookups . It's OK that Firefox uses the local DNS when Clouldflare cannot resolve the host name in order to preserve the ability to perform local network lookups. It is not OK for Firefox to silently always use the the local DNS when Cloudflare is down or can't be contacted.

A malicious Access Point operator could simply block Cloudflare DNS and cause Firefox to use use the malicious local DNS without user notification when network.trr.mode = 2.

When network.trr.mode is 2 or 3, Firefox should always warn the the user that Clouldflare can't be contacted and DNS lookups are insecure.

If you have intentionally set network.trr.mode = 2 then it's "2 - TRR first", in practice: try DoH, if it fails, do local resolution. So it's not a bug, it's expected. There will be no warning and we will not implement it.

If you see a fallback to local resolution in mode 3, then it is a bug! In mode 3 it's expected to never use local DNS and rather show a "Host not found" error page and never load anything.

Please make clear for what settings you get what results.

Thanks.

This sounds like the documented intended behavior -- in the default configuration there are lots of ways to disable DoH or trigger local fallback, both for policy and reliability reasons. Maybe in the future we can default to a more locked-down approach, but not initially.

Some additional information about our DoH rollout and settings:

• About the US Rollout of DNS over HTTPS mentions "fallback" mode
• Configuring Networks to Disable DNS over HTTPS
• https://wiki.mozilla.org/Security/DNS_Over_HTTPS has links to our heuristics

The failover is good when a Cloudflare returns NXDOMAIN. However, if Cloudflare can't even be contacted, the local DNS will be used for ALL lookups. Thus, a malicious hotspot can simply block Cloudflare DNS and Firefox would silently use its poisoned DNS without any user notification.

I apologize for not being clearer earlier. Hopefully the below pseudocode is clearer..

Current Firefox trr=2 DNS failover lookup logic.

if (cloudflare_dns_lookup returns NXDOMAIN) or (cloudflare_ping_test returns host_is_down) then
if (local_dns returns NXDOMAIN) then
print "Hmm. We’re having trouble finding that site."

Suggested change

if (cloudflare_ping_test returns host_is_down) then
print "Warning: unable to contact Cloudflare. DNS over HTTPS is unavailable"
else if (cloudflare_dns_lookup returns NXDOMAIN) then
if (local_dns returns NXDOMAIN) then
print "Hmm. We’re having trouble finding that site."

This notifies the user that Cloudflare is either blocked or down so DoH
is unavailable and the user is vulnerable to DNS poisoning. Without this
change, a malicious hotspot could simply block access to Cloudflare DNS
(https://mozilla.cloudflare-dns.com) and Firefox would silently use the
local, poisoned DNS for all lookups.

This change still preserves the failover to the local lan DNS when Cloudflare
can be contacted but can't resolve the host name (NSDOMAIN).

Current Firefox trr=3 DNS failover lookup logic.

if (clouflare_dns_lookup returns NXDOMAIN) or (cloudflare_ping_test returns host_is_down) then
print "Hmm. We’re having trouble finding that site."

Suggested change.

if (cloudflare_ping_test returns host_is_down) then
print "Warning: unable to contact Cloudflare. Internet is unavailable"
else if (clouflare_dns_lookup returns NXDOMAIN) then
print "Hmm. We’re having trouble finding that site."

Since trr=3 requires Cloudflare, no DNS lookups can occur when Cloudflare is
either down or blocked so in effect no Internet is available.

Hope this helps.

DoH is a major change to fundamental internet technology and we are intentionally rolling this out in a cautious, "best effort" way. We aren't even 100% sure the resolvers can handle the traffic. We already overran one partner by sending too large a percentage of traffic. People trust Firefox to handle their web browsing and we can't afford to make any one resolver a single point of failure. And since we don't know if the resolver is down/unreachable due to an attack or not we're currently erring on the side of keeping users happy and browsing.

For now DoH is intended to add privacy protection against passive traffic monitoring. It is not yet being used as a robust protection against other things that are already problems with DNS. (e.g. if DoH had not been invented users would remain vulnerable to local DNS poisoning.) We haven't even rolled this out around the world yet! We do have stricter modes, and perhaps your suggested algorithm change would allow us to roll that out sooner/with less breakage, but we don't need to treat this as a confidential security "bug". At this stage aggressive failover is a desired feature.

Thanks for your responses.

People trust Firefox to handle their web browsing and we can't afford to make any one resolver a single point of failure. And since we don't know if the resolver is down/unreachable due to an attack or not we're currently erring on the side of keeping users happy and browsing."

Why would you want to keep users ignorant when the DoH host is down or unreachable? You have an http/https indicator on the web browser. Why not at least an DoH host reachable/unreachable indicator as well?

For now DoH is intended to add privacy protection against passive traffic monitoring.

How does DoH add any privacy or protect against traffic monitoring? Firefox is still connecting to any IP address provided by DoH. All Firefox connections are easily monitored by the WiFi portal or anyone else unless you use TOR or a VPN. DoH does not provide protection against traffic monitoring. The main benefit of DoH is to protect against DNS poisoning. Unless a user has an indication whether or not a DoH host is reachable, that protection is limited at best.

At this stage aggressive failover is a desired feature.

Note that I am not saying that the user needs to know if a DoH host returns NXDOMAIN. Failover to a local DNS is fine under those circumstances. The user only needs to know if the DoH host is reachable.

(In reply to Vernon Van Steenkist from comment #6)

Thanks for your responses.

People trust Firefox to handle their web browsing and we can't afford to make any one resolver a single point of failure. And since we don't know if the resolver is down/unreachable due to an attack or not we're currently erring on the side of keeping users happy and browsing."

Why would you want to keep users ignorant when the DoH host is down or unreachable? You have an http/https indicator on the web browser. Why not at least an DoH host reachable/unreachable indicator as well?

This is a UI problem, and a user education issue. Most users don't know what DNS, DoH or HTTPS really means.
We're actively working on a better UI and settings for DoH, and should have something ready around Firefox 82-83.

For now DoH is intended to add privacy protection against passive traffic monitoring.

How does DoH add any privacy or protect against traffic monitoring? Firefox is still connecting to any IP address provided by DoH. All Firefox connections are easily monitored by the WiFi portal or anyone else unless you use TOR or a VPN. DoH does not provide protection against traffic monitoring. The main benefit of DoH is to protect against DNS poisoning. Unless a user has an indication whether or not a DoH host is reachable, that protection is limited at best.

You are correct, individual users are not protected against an active attacker on the network. In that case, by design DoH can't ensure complete privacy. However, when deployed at scale it ensures that passive actors can't collect all the data without being detected, or at least they would have to spend a lot more resources to do so.

At this stage aggressive failover is a desired feature.

Note that I am not saying that the user needs to know if a DoH host returns NXDOMAIN. Failover to a local DNS is fine under those circumstances. The user only needs to know if the DoH host is reachable.

I think that's fair. We recently had the same issue when a user inserts an invalid URL for the DoH endpoint. There's no indication that something's wrong. We'll try to add a feedback mechanism as soon as possible.

We'll try to add a feedback mechanism as soon as possible.

Thanks!!

At least one major ISP in the UK is now blocking mozilla.cloudflare-dns.com by default. This prevents Firefox from using DoH (regardless of settings or heuristics).

$ dig +short mozilla.cloudflare-dns.com @1.1.1.1
104.16.248.249 
104.16.249.249 

$ dig +short mozilla.cloudflare-dns.com
90.207.238.183 

The latter address is a host for the ISP's block page, in this case Sky Broadband. There reports from other users dating back 3 months on Reddit.

Further testing, other DoH providers are also blocked.

 $  dig +short dns.google
90.207.238.183

 $ dig +short dns.nextdns.io
90.207.238.183

 $  dig +short doh.powerdns.org
90.207.238.183

 $  dig +short dns.quad9.net
90.207.238.183

However, https://1.1.1.1/dns-query (Cloudflare's non-Mozilla offering) works fine and can be set using the custom option in Firefox.

So, the issue described in comment 0 is really pointing out the possibility for phishing, if you are e.g. on an untrusted network and they are trying to make you visit a fake site. In particular, one needs to have placed what I would currently describe as excessive trust in DoH - and that's part of the problem, that it is not clear how reliable DoH is and from what one is protected with its use, just from looking at the UI.

Generally, the fact that it's possible for networks to "force" use of native DNS by simply blocking the DoH endpoint is a well-known state of the ecosystem and e.g. we have the canary domain to support this (at least in case of our automated rollouts).

With all this in mind, this is P3 until we have more direction from e.g. Product on how we want to evolve here.