> 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?).