...and a local HOSTS file.

So now it will, by default, contact all the ad/tracking hosts that you configured to be blocked.

"But now your DNS queries to those ad/tracking hosts are encrypted!"

No. I don't care. I didn't want to connect to those hosts in the first place.

Even worse, corporate intranet addresses get leaked.

Everyone on this article saying it's FUD is either a framework junky, isn't seeing the bigger picture, or just focus on one wrong thing in the article.

It's actually FUD, because it's missing some important points

> For starters, Mozilla said that after it turns on DoH by default for US users, Firefox will contain a mechanism to detect the presence of any local parental control software or enterprise configurations.

> Additionally, Mozilla is also working with ISPs to make sure users won't use DoH as a way to bypass legally-set blocklists.

> The organization said it's been asking ISPs and providers of network-based parental control solutions to add a "canary domain" to their blocklists. When Firefox will detect that this canary domain is blocked, it will disable DoH to prevent the feature to be used as a filter-bypassing solution.

https://www.zdnet.com/article/mozilla-to-gradually-enable-dn...

I hardly see how the OP is FUD. What the article states is true; just because you can opt-out doesn't mean it's wrong.

Where you are drawing the line is the opt-out to disable it, as opposed to the convention of opt-in.

Think about companies in the 50-200 employee range; As a sysadmin, I have to purposefully go out of my way to put that domain (use-application-dns.net)[1] in my root resolver, and point it to NXDOMAIN.

I can't do it if another provider is managing my DNS (ISP, cloud service...); it also doesn't actually guarantee that it is off.

> If a user has chosen to manually enable DoH, the signal from the network will be ignored and the user’s preference will be honored.

The basic IT mantra has been 'If it aint broke, don't fix it.' Mozilla itself is moving fast and breaking things; which is why we have standards in the first place.

For god sake, there isn't even a proper RFC to select yes or no to DoH.

I, as a sysadmin, must not only implement the domain in my resolver, but I also must keep in my mind that if a user is using Firefox, that there are things it does internally that are not right, and it is easier for me to have my users on Chrome, because it is less of a headache for me.

[1] https://support.mozilla.org/en-US/kb/configuring-networks-di...

Indeed, Firefox is prioritizing the interests of users over the interests of sysadmins. Personally, I'm fine with that.

> The basic IT mantra has been 'If it aint broke, don't fix it.'

An unencrypted protocol that compromises privacy may not be "broke" for sysadmins, but it is for users.

Well, now CF will know per-organization IT structures. All those LAN-only administrative interfaces, and, with link prefetching, internal resource maps could be built in just a few clicks , using account with sufficient privileges. This is such a security-defying move by Mozilla I can't even start. And CF DNS logs will be the obvious first step for every targeted attack.

Sure, if your targeted attacker has managed to compromise Cloudflare first… Not exactly a trivial prerequisite. If you have any kind of VPN or Wi-Fi access to your network, those domain names are already leaking to other DNS providers whenever someone accidentally accesses a URL while on the wrong network.

Also, if your internal resources are using publicly trusted SSL certificates, the domain names are already being broadcast to the public thanks to Certificate Transparency. If you’re sophisticated enough to run a private CA for them, then you’re probably sophisticated enough to set up use-application-dns.net as well – though I still wouldn’t recommend ever treating domain name secrecy as a meaningful security boundary, considering how many ways they can be leaked. The remaining possibility is that your internal resources aren’t using SSL at all... in which case you have bigger problems than domain name leaks.

How is it in the interest of users if they can't access the intranet servers anymore?

They can, it just takes extra steps.

Firefox tries DoH via Cloudflare, for an internal domain that returns NXDOMAIN (Cloudflare can't answer for your internal resolver,) then they fall back to local resolvers, which is OS based (DHCP or statically set.)

The response time to complete the internal request goes up, because you're sending data to Cloudflare, they can't find it, then the 'normal' response time for internal resolvers.

Edit: Made more clear.

> They can, it just takes extra steps.

For 99% of users, that means they can't.

Luckily for them, they probably aren't allowed to use Firefox anyway, and are stuck using Edge or whatever, and the local MCSE will use this as another reason why Firefox may not be used by anyone.

You know that Chrome is also planning a similar switch?

https://www.silicon.co.uk/workspace/browser/google-chrome-do...

Yes, however the difference here is that Chrome is looking at the OS resolver itself first; not just disregarding it, or looking for a magic domain. Chrome is being opt-in, Firefox is being opt-out.

Chrome DoH use cases:

For the average home user, fine; they're either using what the ISP DNS is, or the public ones (1.1.1.1, 8.8.8.8 ....) If those are on the 'accepts DoH from us', then it'll use DoH to the appropriate destination.

For the corporate environment, their internal DNS might not support DoH, and as such, Chrome will not even try to use DoH.

The key is that it is respecting the OS DNS settings, not the ability to not resolve a magic domain. If I opt to setup DoH internally, the understanding is that I know what I'm getting into.

> When Firefox will detect that this canary domain is blocked, it will disable DoH to prevent the feature to be used as a filter-bypassing solution.

...then what is the point of having DoH in the first place? Anyone who wants to intercept your DNS traffic will use the canary domain and force Firefox to disable DoH.

> Additionally, Mozilla is also working with ISPs to make sure users won't use DoH as a way to bypass legally-set blocklists.

Wait, what? Surely making DNS private and non-censorable is the whole point of DoH?

Corporations concerned about that should be blocking DoH anyway

How can you block it, if the browser itself is doing the communication, over https no-less?

DoH was made to stop censorship, which includes blocking; if you could just block it, then whats the point of DoH?

DoH uses regular DNS to get the IP address of the DoH server. So they could just block queries for the most popular DoH servers.

Any device at home an go to http://nas and get on my nas, "http://desktop", "http://router", and "http://shed" and get on those.

How does that work in this bold new future? I'll have to register a domain name and add a bunch of A records for 192.168.0.1, but then it still won't work -- I'll have to do "http://desktop.mydomain.com".

Worse, while going to "shed" will work in chrome, it will fail in firefox. My guest network captive portal may well break too if someone visits with firefox.

I don't know why you're downvoted, because that is a very good question.

What you have to do is add an entry in your local nameserver for domain use-application-dns.net and set it to NXDOMAIN. See https://support.mozilla.org/en-US/kb/configuring-networks-di....

Hopefully Google will use the same method for disabling DoH in Chrome. But I won't be surprised if they're going to force DoH even harder, and make it even more difficult to turn off.

Firefox claims they will detect this situation and disable DoH.

Detect it, how? By forwarding the request to a local resolver after DoH fails, and thus leaking information?

Do you... really care if someone outside you network knows the domain you chose for an internal network service?

That's not sensitive information. Also, there's basically no way for cloudflare, even if they were being malicious about it, to collect and use that information. What would they do with it?

Yes, I care. Why don't you? I work for Tier 1 banks. They are paranoid, and rightly so. One of their many paranoid rules is that hostnames can never betray the machine's purpose. You could easily analyze DoH stats and deduce certain machines' functions.

Leaking information is bad.

It's definitely sensitive information --- useful for attackers to find out the structure of the LAN.

Happy to see someone understands the real problem here!

What's wrong with uBlock Origin?

Yes, Pi-hole works via setting it as a DNS server, which this will bypass by default.

You will have to turn it off manually, in Firefox.

Not a great direction for DNS to be going for things like Pi-hole. If DoH becomes a thing on say smart TVs and gaming consoles, I fear it will be baked in and not configurable. Also going to be annoying on PCs/phones if each individual application is going to get its own DNS config now.

Would it be hard to make pi-hole into a DoH provider so you could just point your browser at it? Or does that defeat the "just works" factor of the pi-hole?

Probably easier to just turn off DoH in Firefox.

In a home LAN configuration, which I'd expect is the vast majority of Pi-hole setups, I don't think you'd really be gaining anything from DoH.

And even if Pi-hole does support being a DoH server, you'd have to configure that in Firefox anyway.

Presumably you'd want DoH on the Pi-hole in the other direction, so that it's encrypting your DNS requests forwarded out to the Internet. But yeah, there'd be no reason to want to deal with certificates for your local network machines to do DoH from Pi-hole to PC.

I don’t imagine it would. It might be there already. The real problem was mentioned above. We risk a situation where each app has its own doh config and not all of them allow you to change it. There’s nothing necessarily wrong with doh. It’s that app developers are baking it into apps instead of the OS where it belongs.

Yes, a DoH request would never hit your Pi Hole

Yes, unless you configure Firefox to not use Cloudflare DoH.

...unless you disable it. However you can configure firefox to use your pi-hole if you can get it serving dns over https. If that's not supported now I would expect it becomes supported very soon.

then some "brave" company like apple/mozilla removes the option to disable it

There is no conceivable reason as to why anyone would remove the ability to configure DNS servers. DNS server options are present in almost all internet-facing applications and devices, from locked-down ecosystems like iOS to touchscreen printers and game consoles. You're just spreading FUD.

How do you imagine apple will remove an option from mozilla?

One option would be to worry about mozilla turning off the ability to disable this if they ever actually do that.

Out of the box? Yep! I realise that will annoy people but honestly it's a good thing - any solution that would not bypass a pi-hole would allow governments and ISPs to do the same.

To retain your pi-hole, you'll need to run a DoH proxy on your pi-hole device, configure your browser to use that as the DoH provider, and this will allow your pi-hole to inspect and modify DNS results. Your pi-hole can then use any upstream DoH provider that you want.