Yes, if you press the network and proxy settings in the preferences page, you will see a DNS over HTTPS setting. You can also use this to set your own resolver in case you dont trust cloudflare.

> The comment about having “no plans” to enable this outside the USA seems a bit disingenuous

The comment actually very clearly says "we do not have plans to roll out the feature in Europe or other regions at this time".

Also I have mixed feelings about this. On one hand yeah, encryption is great and someone sitting between me and my ISP will no longer be able to monitor my DNS queries. On the other hand I don't feel like this is protecting me from anything at this time. Instead of trusting my ISP, I have to trust Cloudflare. And in the meantime my ISP still knows where I am connecting to, between looking at the IP and the SNI (they mention ESNI but we're not there yet and it still just a partial fix).

DoH (in general, not Mozilla's problem) just enables any piece of software or hardware on my network to bypass any security controls I have in place. No more filtering DNS with things like PiHole, no more blocking DNS port on your firewall. This tends to work out great for Google and any random IoT device manufacturer. I could cover this with more enterprisey setups but that's the last thing I want to do at home.

So the average user probably sees no difference either way, nothing lost, nothing gained. But for me it's a clear regression because I lose the little control I had over that traffic and I just spread more data around to yet more companies. Some may even be in legal jurisdictions that are even less trustworthy than where my ISP is located.

> DoH just enables any piece of software or hardware on my network to bypass any security controls I have in place.

I think this is an error in how you've thought about the problem. If your "security controls" depend upon other people volunteering to use some protocol then those weren't "security controls" they were more like "guidelines".

[ My local airport has a sign and a telephone so that if you've arrived with goods that are forbidden or without permission to enter the country you can call up the relevant authorities and have them come fine or arrest you. The telephone looks dusty. Do you think maybe people just decide not to call? ]

Mozilla does also have a programme https://iot.mozilla.org/ about how to design IoT devices that allow their owners to control them rather than trying to bodge things by hoping they use protocols you can intercept.

> If your "security controls" depend upon other people volunteering to use some protocol then those weren't "security controls" they were more like "guidelines".

It isn't really a matter of security controls. Anything has always been able to create an encrypted tunnel on TCP/443 and send whatever over it.

The issue is administrative cost for cooperative applications. You have a local DNS that e.g. blocks known malicious domains and has the local names for other devices on your LAN. The user of each device doesn't want to prevent this, the application developer doesn't want to prevent it, but making that happen when applications default to using a third party DNS goes from setting the DNS via DHCP to changing a separate setting in every application on every device.

The suggested solution to this is to have the local DNS resolve a canary domain in a particular way which Firefox takes as a request not to use DoH by default. That basically works, but I still don't know what they intend to do when adversarial upstream DNS servers start resolving the canary domain that way. It would also work a lot better if there was a standard canary domain instead of every application making up their own.

> If your "security controls" depend upon other people volunteering to use some protocol then those weren't "security controls" they were more like "guidelines".

It's not about volunteering. Previously I could block udp/53 and tcp/53 and be confident of the fact that no DNS look ups would happen. (DNS queries over other ports could be caught doing packet sniffing.)

Now I have to worry about DNS queries going out via HTTPS. So if I want to monitor my network for malware contacting a C&C server I have to snoop HTTPS. Which means I now have to install a web proxy and perhaps do MITM.

Previously I could 'simply' monitor DNS look ups to see if anything was trying to connect to nefarious domains.

DoH has reduced visibility into my own network.

> Previously I could block udp/53 and tcp/53 and be confident of the fact that no DNS look ups would happen. ... Now I have to worry about DNS queries going out via HTTPS.

That confidence would have been misplaced. DoH offers a standardized protocol, but it's not exactly difficult to put together a one-off interface for performing occasional remote DNS lookups over HTTPS. One could even use existing HTTPS sites for the purpose (e.g. https://ping.eu/nslookup/).

That is a good point, but it is also mostly independent from DoH, a VPN with an hardcoded IP would have worked in the same way (if you look into elusive VPNs you can also find some that work by injecting traffic into padding of another connection).

The only difference is if you are worrying about the traffic leaving your own browser and in that case you can just not enable DoH

My passive network sniffers may throw red flags on suspicious traffic which may end up being VPN. By disguising non-web traffic over the (until now) web-mostly HTTPS, it makes the job of someone who wants to be a responsible netizen and monitor their network that much harder.

I agree if the point is that this might increase the reach of such technologies. But if you are thinking about traffic coming from sources different than your browser then why would they be unable to open a connection on hardcoded IPs?

Also VPN sniffing can be arbitrarily hard, for example if I remember correctly tools like https://www.softether.org/ are designed to work around the Chinese internet firewall.

From my point of view DoH add nothing outside the browser.

So I should block outgoing TLS requests to be able to stop DoH?

Seems a bad idea....

At least with DNS I could run a local DNS server and block outgoing port 53 from anything else. Now I no longer have this option and each app gets to look up what it wants, when it wants. Sure, it's great that my ISP cannot see what's in these requests but nor can I! And it also means that any application (eg. any Google product) can query for advertising/tracking domains without me being able to do a thing about it.

It isn't solving a problem - it's creating a far, far worse one (for me).

If I have got this wrong, or there is a method around this - what is it???

Don't put devices on your network if you don't want to give them network access. And don't block technologies and protocols that help people protect themselves just because they also help devices protect themselves from you MITMing their connections. If you want to run a device reverse-engineering lab you have more work to do to break the security of a device.

Also remember that if you can break the security of a device, so could an ISP router. The correct behavior for devices is to treat the intermediate network between them and the servers they talk to as hostile.

How many people are using custom local plaintext DNS as a measure to analyze local devices on their network? How many more people are having their whole network's DNS usage analyzed by their ISP and anyone their ISP sells data to? The defaults are designed to be the right choice for people who don't change the defaults.

"The correct behavior for devices is to treat the intermediate network between them and the servers they talk to as hostile."

Thanks for this - I had not thought of that.

Looks like I'll be keeping my "smart" TV off the network forever then (my old LG used to send a network request whenever I pressed any button on the remote)! And all my Android devices, Windows 10 devices and my Apple TV and MacBook too. (This is only partially sarcasm - I can't really trust anything these days it seems...). The amount of dialling-out they all do is astronomical. The only solution appears to be going full 1980s and not being on the network. The dream is over.

At least my Raspberry Pi can be trusted. Other than the GPU chipset...

This is precisely why many of us use Linux and put up with some of the inconveniences or doing so - it’s more trustworthy. (And it gets more convenient as more people start using it.)

the irony is that almost all of the smart devices use linux....

They sure do, but it’s a Linux instance that the manufacturer has control over rather than the user. (Which is the real problem, more than just what tech is being used.)

> treat the intermediate network between them and the servers they talk to as hostile

Unfortunately they also treat the user as hostile and untrusted. Your phone, browser, OS, or TV treat you as hostile when they send data to the manufacturer and give you no way of assessing yourself or actually controlling this. We have standards and protocols that ensure the data is kept perfectly secure and inscrutable between your device and the manufacturer but absolutely nothing is put in place to give you any control over this. Your choice is binary: use it or not. Every security decision seems to work out better for those companies than for the user.

In this case both DoH and DoT provide the required security for the users but one of them takes a little bit of control away from them.

The problem is that the device (or website) also treats the owner and legitimate user as untrusted and obfuscates the content of the traffic in a way that makes everything completely opaque for them. The device/site only trusts its manufacturer which makes any device that completely obscures its traffic from its owner feel more like a Trojan horse. This is how you end up with questionable telemetry and data leaks for example.

What's a "trustworthy" device in this circumstance? If you can never verify then it's not trust it's faith and hope.

In what way does this argument not also suggest that the device should use plaintext HTTP so that you can intercept all its other traffic?

What I want is a key to my own house, not an open door. Right now using a lot of software and IoT devices feels like buying a house but the builders keep the only key.

> Don't run devices on your network you don't trust.

This advice is about as practical as "Do not use ISPs and their forwarders that you don't trust.". Which is to say, not much. Let us know about your experience with smart TVs and similar devices, and how much you trust them.

> Don't run devices on your network you don't trust.

Oh, is that all?

How about I trust the devices until a secretary clicks on a (spear)phishing link that runs a zero-day. Then what? The host is compromised so I can no longer trust any end-device monitoring software on it, and now the network traffic is opaque.

And that doesn't even get into things like academia where students and visiting researchers bring devices of unknown providence. If if they're on DMZed networks, they could be spewing garbage onto the Internet and getting my CIDR range blacklisted.

So you're counting on malware's continued use of plaintext DNS as part of your network's security strategy?

If anything hits port 53 on the outgoing gateway, and it's not from our recursive servers, then we know that network element needs to be looked at: either it's mis-configured or malicious.

Anything that uses our recursive servers is monitored, and we can check against blacklists, either in real-time or after-the-fact through logging.

* https://en.wikipedia.org/wiki/Domain_generation_algorithm

* https://en.wikipedia.org/wiki/Botnet#Domains

If malware is connecting to hard-coded IPs then there's nothing we can do about that.

So yes: monitoring DNS for suspicious activity is part of our security strategy.

Then your security strategy definitely needs improvements, since malware often uses hardcoded IPs to bypass DNS proxying/forwarding that corporate networks use. Seriously, this argument could be used to say we should be using HTTP instead of HTTPS, but anyone doing security knows if they really need that level of introspection they need to MITM HTTPS traffic with a MITM proxy. If you care that much, you also need to MITM DoH/DoT traffic.

DNS sniffing takes care of a lot of low-hanging fruit.

Given that Cisco has a major product, Umbrella, that is sold as a part of enterprise security strategy I'd say that more than the OP is considering DNS filtering / monitoring as part of a network security strategy.

> If your "security controls" depend upon other people volunteering to use some protocol then those weren't "security controls" they were more like "guidelines"

> Security controls are safeguards or countermeasures to avoid, detect, counteract, or minimize security risks to physical property, information, computer systems, or other assets. [0]

Of course it's a security control. Not a perfect one but a security control nonetheless. And every security control of today might become useless tomorrow so I don't get your point. Is a firewall a "guideline" just because I can tunnel some illegitimate traffic through an accepted port? Are your house and car door locks "guidelines" because a thief has to "volunteer" to not break/pick them or go in through the window? So you'll take them all out until you have "real" security controls? I guessed not...

As for your airport example, given that illegal activities go unnoticed and items are smuggled through customs every day you could argue that there are no security controls in place and that the airport relies on people volunteering to not break the law. But you'd be using the wrong definition and understanding of what a security control is.

As far as home security goes having DNS filtering adds a layer on top of the "nothing" you normally have. And it's a pretty good and accessible way to achieve this extra bit of security. "Not perfect" does not equal "no security". And it's not even just security: ad-filtering, parental controls, privacy, etc. are all impacted. DoH all but guarantees that you lose this control and unfortunately there's nothing ready to take its place.

[0] https://en.wikipedia.org/wiki/Security_controls

Why? If you know how to run your own pihole, you know how to turn off DoH? You're not being forced into this, a default setting is getting flipped and you're entirely free to go "no thanks" and flip it back, so if you trust whoever owns the IP that you're using as real, unencrypted DNS server, then just keep using that. Same as for folks who want to keep using unencrypted emails "because encrypted mail isn't fully encrypted anyway and just makes things harder".

As tech changes, solutions change, but at least for the foreseeable future your DNS intercept will keep working just fine until everyone switches over to DoH and stops offering an opt-out.

> DoH (in general, not Mozilla's problem)

Parsing the text helps with understanding it. And the fact that Mozilla allows me to flip back says nothing about those general cases. I do not expect everyone to give you the choice.

You may find it noteworthy that Mozilla provides ways to configure this behavior as you please: https://github.com/mozilla/policy-templates#dnsoverhttps

> DoH (in general, not Mozilla's problem)

You may find noteworthy that my comment had 2 points. One where I don’t feel like DoH will bring much benefit in the browser today, and one where DoH in general will just give you, the user, even less control over what you’re sending out. I can’t imagine everyone giving you the option to switch, all the TRRs being actually trusted, or even being able to pick the TRR in most setups (IoT? Your random Google product?).

> What’s in it for the Cloudflare & NextDNS?

It gives them a competitive advantage in DNS industry against other B2B providers, such as NS1.

How?

Surely the only way that's possible is if they derive data about users, which they can then sell .. which is what Mozilla claim to be preventing.

Cloudflare's resolver does not send the client subnet, which hurts performance when users connect to anything that doesn't use Cloudflare.

That's one thing, sure, but that doesn't affect the majority of sites. CF's DNS POPs are likely more dense than the great majority of service providers POPs. So using the subnet of the resolver is about as good (if not better) than having ECS info for practical purposes. (Because the client is normally going to hit the closest DNS POP to them in BGP network distance.)

I'm not a CF fanboi, in fact I think they are evil. But let's not make weak arguments. That said, yeah suppression of ECS info is a deliberate anti-competitive choice by CF. They probably have convinced themselves its about privacy, but it isn't.

The real benefit to them is, as the CDN, they get the benefit of even lower latency and even better control. With a penalty to everyone else.

It's a disgusting arrangement, and a net loss in privacy. Your ISP already knows what websites you visit, they don't need the DNS because they see the actual traffic.

I'd find it more palatable if these so-called TRR providers were required to be DNS-only. Maybe DNS + registrar.

>Your ISP already knows what websites you visit, they don't need the DNS because they see the actual traffic.

Then why were the big ISPs lobbying against this plan when proposed by Google originally? Because they truly were concerned for the welfare of the Internet as they claimed? This is a concern they've never exhibited in the past, their only demonstrated concerns have been related to their revenue streams.

> How?

Running a public DNS service allows Cloudflare and NextDNS to provide faster and smoother DNS updates to their B2B customers by avoiding third-party DNS resolvers and caches.

curious, can see the case for the capability giving advantage, but how do you think running the public service would? or do you mean competitive advantage in marketing their products?

> having “no plans” to enable this outside the USA seems a bit disingenuous.

Other countries have censorship (China, UK, New Zealand, etc) whereas there is none in the US.

I wonder if that’s why?

Mozilla was founded in USA, which may be of relevance for why USA was selected as the country of launch. I don’t know anything specific about their decision, though.

it's probably because cloudflare and friends went "we want to see what hit we're taking if we do this for free for you, by only enabling this by default for the US first" or something.

Huh? It works for me in the Netherlands, at least, it is in the settings. How to confirm if I'm using it?

Go to about:networking and look at the DNS tab

I'm in Canada and TRR is indeed marked false for every domain.

Strange. I'm also in Canada, but TRR is marked true for every domain.

If you use it, presumably you can make a GDPR claim to find out way Cloudflare are doing with the data?

After eSNI becomes mainstream, network level ad blocking will be extremely difficult. My guess is there will be a huge ad blocking subscription play in the future.

They’re usurping control and calling it a privacy enhancement so they can sell the control back to us with per user per month pricing.

Will they roll it out in Canada? Raising eyebrow and thinking if it has anything to do with GDPR

Collect data of course. Mozilla is very naive to trust that they won't collect data (be it personal or otherwise). Neither they nor the enduser can ensure that.

In order to be included in Firefox, they needed to agree to the DOH-resolver policy[1]. That states that:

> We intend to publicly document violations of this Policy and take additional actions if necessary.

I believe that those "additional actions" will prevent providers from violating the policy. If not, they will be removed from Firefox.

[1] https://wiki.mozilla.org/Security/DOH-resolver-policy

Mozilla doesn't trust. That's what the legal team is for. All this stuff is covered by contracts and audits.

Who is more likely to abuse it though, those guys or your ISP? Security is never 100%, it's whack-a-mole

I don't know, that wasn't the point though. At least with the ISP I am a customer, not a product.

And we all know what the ISP business model is. We have a right to ask what Cloudflare is getting out of this.

We've seen the "don't be evil" free stuff thing turn sideways before.

> What’s in it for the Cloudflare & NextDNS?

I'm amazed noone else is asking this. CF's whole business model centres around the concept of denying website access to minorities they classify as "bots". Some big actors can afford to practice the notion of reciprocity by blocking access to Cloudflare in return — https://news.ycombinator.com/item?id=21155056 — try doing that now when you might end up blocking access to your site for all Firefox users.