You don't get to control what my devices do just because you control a network they're transiting through. Even if DoH had never been standardised, clearly my devices can do this anyway.
On the other hand, if you actually control your devices DoH shouldn't be a problem, you can have them talk to whichever servers you prefer regardless of the protocol.
As to the lightweight thing. We get a few benefits from running DNS on top of HTTPS rather than say TLS (which also exists, as DoT)
1. HTTPS allows us to put parameters in the URL which are thus confidential (HTTPS will encrypt them) and have those control the DNS lookup. So dns-server.example can offer all its users their own URL, even though they all talk to the exact same server (dns-server.example.com) and a snoop can't tell that one device used the rank0 account while another device used the tialaramex account, those are encrypted in the URL, yet the actual server can see which is used and maybe my devices get "pure" answers while yours have ad-blocking or whatever.
2. DNS doesn't have a rich error vocabulary. For your ad-blocked domains, a traditional DNS server has to either lie (bogus answer) or claim no answer exists (NXDOMAIN or OK 0 answers) but HTTP has a rich variety of error codes. Maybe 403 Forbidden is appropriate for the Xian parent who doesn't want their teenager looking at pornhub.com and 451 Unavailable For Legal Reasons is appropriate for a DNS service which excludes Pirate Bay due to lawsuits.
> You don't get to control what my devices do just because you control a network they're transiting through.
And if I run a guest wifi in one of the many countries where I have legal obligations to take steps to block illegal traffic because I am ultimately responsible for the emissions of my network, what would you suggest I do?
> DNS doesn't have a rich error vocabulary. For your ad-blocked domains, a traditional DNS server has to either lie (bogus answer) or claim no answer exists (NXDOMAIN or OK 0 answers) but HTTP has a rich variety of error codes.
It's a good thing that DNS has a limited vocabulary of error codes. I want the garbage website to think it couldn't load the ad because of a mysterious DNS issue. Having a reason like "DNSHTTP 486: Blocked by Client" would just make it that much easier for the site to deny you access/track you/detect your blocking activity.
As with steps someone might have a legal obligation to take to prevent people from thinking negative things about the King or to prevent six from being an even number, you should do whatever you feel is appropriate. It might even make a difference. Perhaps you could put up a notice which says "I run guest WiFi here and I have legal obligations to block illegal traffic so, don't do anything illegal".
It's certainly weird to insist it's everybody's else's problem that you're subject to legal obligations that may be impossible to fulfil.
If the purpose of this "obligation" is to ensure nobody is technically compliant and so they can arrest, imprison or even execute whoever they want, it doesn't seem like that's my fault, or Mozilla's fault, or any of the authors and acknowledged contributors for RFC 8484. Any more than it's Giuseppe Peano's fault that six is even.
And if (as seems most likely) they're just covering their backside, the notice is probably sufficient.
> And if I run a guest wifi in one of the many countries where I have legal obligations to take steps to block illegal traffic because I am ultimately responsible for the emissions of my network, what would you suggest I do?
This is an oft overlooked part of these discussions. I manage a public network at a library (which is still the only access point for many people, unfortunately). DNS blacklisting certainly isn't the only tool in the toolkit, but it is one that DoH takes out. I'm genuinely conflicted on DoH because on one hand, I am a privacy advocate, but on the other I run a public network and that comes with certain obligations, both legal (we need to block filesharing) and to customers (we do traffic shaping because the budget it limited and bandwidth isn't cheap).
You do what every company does. Deploy industry standard methods and record your processes. And then when someone comes asking, you show them you did everything right and that is usually the end of it.
That's not the case in the US. Our ISP will absolutely be within their rights to cancel our service if someone on our network is violating their TOS. And we don't really have the money or the standing to fight it.
A world where it’s the local public network operator’s problem to filter client traffic came and went with TLS. You already live in a world where someone who wants to bypass your restrictions can do so trivially. So if you’re not in legal hot water today you won’t be tomorrow with DoH. You deploy whatever non-functional product your country requires for filtering and wash your hands of the responsibility.
> On the other hand, if you actually control your devices DoH shouldn't be a problem, you can have them talk to whichever servers you prefer regardless of the protocol.
I already do tell the devices I control which DNS servers to use via DCHP and IPv6 RA. Firefox is choosing to ignore that by default, and now I have to go through extra steps to solve a problem that Mozilla created by not simply re-using the previous solution (gethostbyname(3)).
At the very least if they had simply used the already existing DoT, instead of inventing a new protocol (DoH), I could have monitored port 953 traffic and see which devices were broken. Now I have to figure out devices trying to sneak through my policies.
It's good that they didn't use DoT, because then it would be too easy for adversaries who want to do censorship or surveillance to just block port 853.
Do you think that DoH prevents adversaries from doing censorship and/or surveillance?
> DoH encrypts precisely zero data that is not already present in unencrypted form. As it stands, using DoH only provides additional leaks of data. SNI, IP addresses, OCSP and remaining HTTP connections still provide the rest. It is fake privacy in 2019.
> DoH encrypts precisely zero data that is not already present in unencrypted form.
What's the point in locking my front door if I leave my window open? And what's the point in closing my window while my front door is unlocked?
This argument is circular. If you want to secure something that is widely insecure, then you have to start somewhere. It's not like people are ignoring SNI and IP addresses. They're just being handled in separate efforts than DNS is.
> Think that ESNI will save you? Well that's being blocked
If you're working with the assumption that any serious attempt to secure hostnames will eventually be blocked, then what's the point of anything at all? Should we just completely give up on security/privacy because the state won't allow it?
We can address ESNI blocks as a separate effort from DNS. We don't have to do literally everything at the same time, it's OK for us to gradually move towards better security and address each problem one at a time.
> Do you think that DoH prevents adversaries from doing censorship and/or surveillance?
Given the amount of complaining I'm seeing from multiple network operators on this very article, yes, there's a pretty strong likelyhood that it helps. Because if it didn't, then network operators wouldn't be complaining about it.
How do you square "DoH is useless" with these kinds of comments in your own linked articles?
> In a paper published last month, the SANS Institute, one of the world's largest cyber-security training organizations, said that "the unmitigated usage of encrypted DNS, particularly DNS over HTTPS, could allow attackers and insiders to bypass organizational controls."
> "The trend is unmistakable: DNS monitoring will get harder," the Dutch agency said.
> The Internet Watch Foundation (IWF), a British watchdog group with a declared mission to minimize the availability of online child sexual abuse content, also criticized both Google and Mozilla, claiming the browser makers were ruining years of work in protecting the British public from abusive content by providing a new method for accessing illegal content.
Does DoH make blocking/monitoring content harder or not? Is the UK lying when it says that DoH will make it harder for them to block content at the ISP level?
Sounds like eSNI is useless waste of effort since its intended audience can't use it.
Meanwhile eSNI/ECH breaks network visibility into the networks I'm responsible for managing (at home and work). If I'm supposed to be a good netizen and make sure that I quickly hunt down malware that's gotten on my network(s), blocking tools and techniques to do just that seems… silly.
> Meanwhile eSNI/ECH breaks network visibility into the networks I'm responsible for managing (at home and work).
Well, don't worry about it, since apparently no one can use it and it'll get blocked, right?
I don't understand the simultaneous argument of "this won't be usable because governments will all block it" and "this is going to make it impossible for me to monitor my network." Both of those arguments can't be correct at the same time; if your government won't block eSNI, then it'll be a privacy boost in your country and it's a realistic path for privacy advocates to pursue. If your government does block eSNI, then why are your worried about your personal network?
_You_ are not in control of _your_ devices. Your television will use this technology to report what shows you're watching to the company that manufactured it; the web browser running on your computer will use this technology to report your activity and retrieve advertisements even if you've tried to block them elsewhere.
It amazes me how people think the worlds largest advertising company is pushing DoH out of alturism. That pihole you're running? That 'steals' money from google. DOH gets rid of that.
You can still use ad blocking with DoH. Just pick a DoH server that does so (or run your own) instead of using the default one. Or just use a browser extension like uBlock Origin instead. Nobody's trying to kill your Pi-hole with DoH. They're trying to kill your Pi-hole by serving ads from first-party domains.
You missed the point. OP is talking about app and IoT devs hard coding DoH servers into their products so that they can bypass any tracking, advertising, and privacy restrictions (aka piHole) you put in place.
Yeah there’s nothing about DoH that a Google or any IoT device maker couldn’t have done 10 years ago if they really wanted to bypass local DNS servers.
The companies willing to do this already made their products fail to load when their ad domains could not be reached. I tried pi hole for a week and found every ad infested service would just throw an error.
This also means nothing for firefox. Firefox can not use DoH and iot products can just implement it themselves.
How many people would be interested in an open DNS service, with the publicly configurable rules e.g. blocklists/custom dns configurations, or rule-lists like ublock origin? I am thinking of starting one.
If your television or browser are running proprietary software while having network access, you have already lost.
Anything that you can do as a network admin to control "your" devices, an ISP can do to control its users. The sane way to resolve this conundrum is to fix your network endpoints to run only Free software, as the alternative would be facilitating centralized control on the large scale.
On the other hand, if you actually control your devices DoH shouldn't be a problem, you can have them talk to whichever servers you prefer regardless of the protocol.
As to the lightweight thing. We get a few benefits from running DNS on top of HTTPS rather than say TLS (which also exists, as DoT)
1. HTTPS allows us to put parameters in the URL which are thus confidential (HTTPS will encrypt them) and have those control the DNS lookup. So dns-server.example can offer all its users their own URL, even though they all talk to the exact same server (dns-server.example.com) and a snoop can't tell that one device used the rank0 account while another device used the tialaramex account, those are encrypted in the URL, yet the actual server can see which is used and maybe my devices get "pure" answers while yours have ad-blocking or whatever.
2. DNS doesn't have a rich error vocabulary. For your ad-blocked domains, a traditional DNS server has to either lie (bogus answer) or claim no answer exists (NXDOMAIN or OK 0 answers) but HTTP has a rich variety of error codes. Maybe 403 Forbidden is appropriate for the Xian parent who doesn't want their teenager looking at pornhub.com and 451 Unavailable For Legal Reasons is appropriate for a DNS service which excludes Pirate Bay due to lawsuits.