Closed Bug 1511643 Opened 6 years ago Closed 6 years ago

DoH enabled ignores local dns overrides

Categories

(Core :: Networking: DNS, defect, P3)

Product:
Core
Component:
Networking: DNS
Version:
63 Branch
Type:
defect

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: mvv, Unassigned)

References

Details

(Whiteboard: [necko-triaged][trr])

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:63.0) Gecko/20100101 Firefox/63.0 Steps to reproduce: Configured a DNS override for a DNS record on the system DNS server and set network.trr.mode to mode 2. Actual results: The override is ignored Expected results: The override should be respected. Some more information, obviously this is because DoH bypasses the configured system DNS servers. However before DoH is enabled by default this needs to be addressed somehow. A lot of networks use DNS overides in some way, these would stop working in FF with DoH enabled.
Component: Untriaged → Networking: DNS
Product: Firefox → Core
Blocks: 1434852
Priority: -- → P3
Whiteboard: [necko-triaged][trr]
Probably dupe of 1453207.
Similar but not the same imo, with the hosts file the computer administrator (user or other) would have actively set the entries. With DNS the computer administrator might not be aware of DoH or DNS overrides on a network. The computer administrator (i.e. user) lacking this knowledge would get undesired results when contacting a address overridden in the local DNS server.
The way I see it, /etc/hosts is more indicative of user choice than local DNS overrides, and we still WONTFIXED bug 1453207. Moreover, it seems impossible to detect "DNS overrides" without actually performing the DNS resolution, which kinda defeats the purpose of DoH/TRR. For enterprise networks, TRR can be disabled via an enterprise policy (bug 1484843), or even better, it could be used to point to a local DoH server. For regular users, bug 1450893 might improve user experience.
Status: UNCONFIRMED → RESOLVED
Closed: 6 years ago
Resolution: --- → WONTFIX
See Also: → https://bugzilla.mozilla.org/show_bug.cgi?id=1453207
Does this mean if/when FF adopts DoH enabled by default, support for split-horizon DNS is explicitly dropped?
another disappointing decision from the Mozilla networking team. The purpose of DOH/TRR is flawed from then beginning and you continue to drive this feature which _breaks_ the users privacy and the well working DNS system into a Firefox release as default.
(In reply to Machiel from comment #4) > Does this mean if/when FF adopts DoH enabled by default, support for > split-horizon DNS is explicitly dropped? Not necessarily. Split-horizon is most common in enterprise environments, which may be addressed with enterprise policies. For regular users split-horizon is more of vulnerability than it is a feature. I would personally expect to be able to access the same pages as someone from another country, without my ISP interfering or tracking what I visit. (In reply to Matthias Versen [:Matti] from comment #5) > another disappointing decision from the Mozilla networking team. We're open to technical feedback here, and we'd like to provide a decent alternative to split horizon cases. But as the issue stands, that is very difficult to do automatically without compromising the privacy properties of DoH. > The purpose of DOH/TRR is flawed from then beginning and you continue to > drive this feature which _breaks_ the users privacy User privacy is very important to us, which is why we are trying to improve it as much as possible. I'm not interested in starting a debate in this bug regarding the pros and cons, but I'm open to discussing it over email if you wish. I'm assuming you're already aware of the pro arguments: https://hacks.mozilla.org/2018/05/a-cartoon-intro-to-dns-over-https/ http://bitsup.blogspot.com/2018/05/the-benefits-of-https-for-dns.html

I work with various companies that use DNS Views so that if you are external to the companies network you resolve to externally accessible addresses where if you are coming from an internal network you are resolved to different IP addresses. These addresses may or may not be RFC1918 addresses. In one situation these just resolve to different public addresses that are only accessible over encrypted internal links.

One of the reasons that they do it this way is to allow both Corporate and BYOD devices to access special resources on the internal network with less authentication overhead than if they are coming over the Internet.

So some solution needs to be made available for situations like this where pushing firefox custom configurations to devices is not an option and where deactivation of DoH inside a corporate network is required.

(In reply to oliver.shane from comment #7)

I work with various companies that use DNS Views so that if you are external to the companies network you

We are currently working towards supporting split horizon in bug 1512255.
I encourage you to add your thoughts there - the more technical details you have the better - and it would be helpful if you could point us towards any system APIs that might be useful in detecting such cases. Thanks!

Also, as briefly mentioned earlier bug 1450893 added a pref where you can explicitly exclude domains from TRR so they will continue to use the local DNS (if split horizon doesn't cover your case).

In an enterprise case, network admins can blackhole use-application-dns.net to prevent use of DoH and therefore use local network policies. https://support.mozilla.org/en-US/kb/canary-domain-use-application-dnsnet

You need to log in before you can comment on or make changes to this bug.