Support address overrides for DoH (ala /etc/hosts)
Categories
(Core :: Networking: DNS, enhancement)
Tracking
()
People
(Reporter: pizzadude, Unassigned)
References
Details
(Whiteboard: [trr] fixed via domain exclusions pref in bug 1450893)
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:61.0) Gecko/20100101 Firefox/61.0 Build ID: 20180410220129 Steps to reproduce: Enabled DNS over HTTPS in Firefox Nightly, by setting: network.trr.mode to "2" network.trr.uri to "https://cloudflare-dns.com/dns-query" network.trr.bootstrapAddress to "1.1.1.1" in about:config Went to a site that is blocked in my hosts file ( /etc/hosts on linux ) Actual results: The site loaded and was not blocked, because setting DNS over HTTPS meant that Firefox ignored my hosts file. Expected results: Firefox should parse the hosts file for blocked or redirected entries like this, regardless of if DOH is enabled or not: 0.0.0.0 example.com 127.0.0.1 example.com 192.168.1.1 example.com
|
||
Updated•6 years ago
|
|
|
||
Comment 1•6 years ago
|
||
Technically speaking, none of those entries *block* the name, they provide custom IP addresses for them. The blocking is a side-effect. But yes, with TRR enabled Firefox will use the DOH server as the primary name resolver so your custom addresses will not have any affect if the DOH server returns a working IP address. I consider this a feature-request very similar to bug 1450893.
|
||
Comment 2•6 years ago
|
||
I'm going to mark this wontfix as outside the scope of the TRR feature (for now at least). TRR's pov is that DNS is done by the application and not the OS - this is indeed a corner case for a highly tweaked configuration. If you rely on filtering of DNS, you should not use DoH.
|
||
Comment 5•4 years ago
|
||
If Firefox will not respect /etc/hosts then there needs to be a mechanism by which users can override DNS results, e.g. about:dns-hosts or something like that without having to disable TRR.
|
||
Comment 6•4 years ago
|
||
I agree with Comment 5, I'm going to re-open this bug (instead of filing a new one) to request the ability to provide local overrides of specific addresses (perhaps via a pref that's parsed out) for development/power-user purposes.
|
|
||
Comment 7•4 years ago
|
||
Actually, I guess that works by setting network.trr.excluded-domains !
|
||
Updated•4 years ago
|
|
||
Comment 10•4 years ago
|
||
Before going live with a new website design, I use my host file to override the official IP address that Public DNS points to (so that the domain name points to a testing/staging web-server instead of the current live website site). This is helpful for testing all the absolute and relative links on the site before going live with the new design.
Because Firefox 80 does not respect the host file, I'm having to use Chromium for testing (as it does indeed honor the host file).
If you're not going to honor the host file, please provide some other mechanism for overriding the domain-to-ip mappings provided by public DNS.
|
||
Comment 11•4 years ago
|
||
I use the hosts file often for multiple overrides for DNS look up. Development, Testing, rudimentary family filtering, and ad blocking. Regardless of the original intent behind the hosts file it is used for a number of purposes and use cases that were not originally intended.
Though I modify my hosts file for development and testing that is not my primary concern. I use it for a limited set of sites that I do not want my children going to.
However, regardless of any other reason, Firefox ignoring the hosts file breaks a long standing behavior that many people have come to trust and rely on that other browsers such as Edge and Chrome follow. I personally trust Firefox greatly when it comes to my privacy, however, if it does not honor the hosts file I will have to use a different browser on my children's laptops, which I do not want to do.
|
||
Comment 12•4 years ago
|
||
There was an additional change for hist file parsing in bug 1616252.
We can mark this bug as depends on bug 1450893 and bug 1616252. With those two fixed, I think the issues brought up in this bug are resolved.
|
||
Comment 13•2 years ago
|
||
Still an issue with 78.15.0esr
None of the listed workaround helps (i.e. problem exists despite network.trr.mode set to 0)
This is borderline malicious behavior by a browser, and should be fixed with the utmost highest priority. Moreover steps should be taken to prevent re-occurrence.
Description
•