Hacker News Reader

Comment by DyslexicAtheist | Hacker News Reader

I don't see a benefit of the built in DoH in firefox since it is shifting the trust from my existing DNS provider to cloudflare[1] (based in the US).

Today I discovered that I couldn't just kill the disqus.com requests with my usual method by sink-holing them in /etc/hosts because for some reason firefox ignored the /etc/hosts file. While Chrome seemed to work fine and local dig requests also returned

  disqus.com.  0 IN A 0.0.0.0

I was left dumbstruck.

I was able to override this in the about:config as described in [1].

I really don't like how mozilla ignors what is defined in /etc/nsswitsch.conf because this breaks all the blacklisting rules a user had set up themselves. At least they should have produced a huge warning telling users that this ignores any local blacklists that are in place.

[1] https://ungleich.ch/en-us/cms/blog/2019/09/11/turn-off-doh-f...

View on HN

Firefox is doing the correct thing here. Firefox cannot read /etc/hosts without breaking some applications since NSS is a series of black-box modules that Firefox can't assume work any particular way. There's nothing special about /etc/hosts on a modern Linux system.

The files module on your system could read /etc/dns or the blarg module could read /etc/hosts but in JSON format.

The thing you're annoyed about is that Firefox with DoH enabled doesn't use NSS at all when performing requests but there is absolutely no way that Firefox can do both -- it either can send requests through the NSS gauntlet and use whatever it returns or not use it at all -- "respecting /etc/nsswitch.conf" is impossible to do correctly.

Linux systems don't provide the right facilities to supplement application level DNS in the way you want. If you want to do DNS in your app you must ignore libc DNS.

Firefox should not be ignoring libc DNS without prompting.

>At least they should have produced a huge warning telling users that this ignores any local blacklists that are in place.

Its not just here, its unfortunately common with firefox. I still cant believe that firefox just silently disables addons if they are no longer supported instead of giving a giant colorful warning.

Is this true if you block the canary domain in /etc/hosts?

https://support.mozilla.org/en-US/kb/canary-domain-use-appli...

I just tested this with dnsmasq[1] and can confirm it works.

It's good to know that there is a method but it looks a bit strange imo (see this article[2]):

>> Now this seems a bit weird: DoH to a public resolver seemed intended to defeat an untrusted local resolver, but an untrusted local resolver can disable the use of DoH to the public resolver in this fashion. In fact, if you have content filtering in place on your DNS resolver, Firefox will also use that as a metric to decide whether or not to enable DoH to the default public resolver.

>> In other words: if the browser detects that one of the things that DoH would help protect against (censorship / content filtering) is in place, then it will not enable DoH. ?? Well, for you as the network provider, that's good news -- you remain in charge, as so often, it boils down to having to trust the things you have to trust -- if you (the end user) don't trust your network provider, you can't use their services to bootstrap a trusted environment.

[1] just add the line for the canary to /etc/dnsmasq.conf:

  address=/use-application-dns.net/

[2] https://www.netmeister.org/blog/doh-dot-dnssec.html

Yeah, this was a surprise to me as well. Spent a while trying to figure out why Firefox wouldn't show a local development instance despite curling it working fine.

If you are using DoH, wouldn’t you need to ignore the local resolv/nsswitch settings? Otherwise your request would get sent out to whatever the configured DNS server is.

I’m sure there is some smarter way to do this, but when you’re handling network configuration at the application level, you’re going to miss local changes (including blacklists).

Maybe he best way to handle this would be to change the system level resolver to use DoH?

> If you are using DoH ...

assuming you means the user-space applications, I agree.

I am not against DoH itself. But the assumption being made here by mozilla is that all users trust the US or US based corporations by default. This might be the case for some people (including myself: in some cases, but not as the default case).

This could have (imo) solved with a couple UI tweaks that educate the user about the implications. Having been protected by my browser extension ad-blockers from most sites it still rendered my second layer of defense (/etc/hosts[1]) useless with this new default. The worst thing is I was unaware of /etc/hosts being useless for several months.

I wish mozilla would make it a core policy that anytime a change makes a trust assumption on behalf of the user in all countries[1] that this is communicated not just in the changelog or blogs but as part of a guided tour, or other visual aids which really spell that trust assumption out.

> Maybe he best way to handle this would be to change the system level resolver to use DoH?

agree, but I also see the difficulty on making the FOSS world agree very quickly on how this is supposed to be implemented as some kind of default (could take a decade or longer, while just pushing it under the radar gives immediate results - that they need to form agreements with various providers, e.g. cloudflare)

[1] they seem to be rolling out different features anyway depending on which jurisdiction you are, as shown in the case of "Mozilla: No plans to enable DNS-over-HTTPS by default in the UK" (which purpose isn't to give freedom[TM] but to comply with the UK nanny-law to ban free speech (and porn, but mostly free-speech)). https://www.zdnet.com/article/mozilla-no-plans-to-enable-dns...

Reply on news.ycombinator.com