As a network guy, the fact that I can transparently redirect DNS on my network to wherever I need to is a nice feature.
As a user of the public internet, it feels like a bug.
As much hassle as things like DoH can be for securing and enforcing policy on a network, it’s about time it became ubiquitous enough that governments can’t leverage DNS for their own purposes anymore.
Honestly I never got the backlash against DoH.
Sounded more like a kneejerk reaction and a meme for something that's an improvement. UDP at this day and age? Come on
My home router is running a (regular, port 53) DNS server that blocks requests to ads, scams, malware, etc. I have rules set up on the router so any port 53 traffic that tries to go to the public internet gets redirected to my router's DNS server.
A device on my network that decides to use DoH without my knowledge or consent gets to bypass all that. I can try to block a list of the DoH providers I know of, but I'm not going to get them all. And it's just regular HTTPS traffic on port 443, with nothing to distinguish it from someone accessing a website.
An antagonistic device on your network that wants to resolve names doesn't need to use DNS at all.
DoH isn't "magic". It's just a simple, standardised protocol. It's existence makes it no more or less easy for adversarial actors to do name resolution.
The choice of DoH is not set from dhcp or the OS, it’s set by the application developer. And that’s wrong.
DNS should be an OS level tool which is consistent to all applications, not an application by application setting.
As the device owner I expect dns to be ck distant whether I run Firefox, chromium, zoom, curl, steam, ping, or he dozens of other programs I run.
Why should it be system wide? That's a broad and imprecise policy vs app by app.
The bigger issue is that it should be an OS level setting. Different apps having a different option isn't the issue, it's any app being able to trivially override a user choice, sometimes without notification.
Again, the existence of DoH has zero bearing on whether or not software written by someone else chooses to use the OS networking stack or even respect your desires when it comes to name resolution.
Again, the point is it should be an OS level setting and apps should respect it. Just because apps can be hostile to user intentions doesn't mean we should allow or worse advocate for that.
I don't see anyone advocating for hostility. Merely the observation that wishing it away is naive.
Well that's odd, since I don't see anyone 'wishing it away' so much as stating apps should respect OS settings and it's reasonable for that to be an expectation of well behaving programs.
A huge shitload of the Internet is the Web.
The reason I force DNS over UDP to my own DNS resolver is not so that chinese-internet-of-shitty-insecure-device (which I don't own) cannot phone home: I do it so that I'm in control of what the browsers can access over HTTPS (my browsers are all HTTPS-only).
Then meet firewalls. The users accounts running browsers on my setup can access HTTPS over port 443 and query UDP to my local DNS resolver. A webapp (i.e. a software written by someone else) is not bypassing that "networking stack" that easily.
Regarding name resolution: except some very rare cases where https shall work directly with IP addresses, a browser using https only will only work for domains that have valid certificates. Which is why blocking hundreds of thousands --or millions-- of domains at the DNS level is so effective.
And if there are known fixed https://IP_address addresses with valid certificate that are nefarious, they're trivial to block with a firewall anyway.
I'm in control of my LAN, my router, and my machines and webapps written by others either respect HTTPS or get the middle finger from my firewall(s). Not https over port 443? No network for you.
Reading all your nitpicking posts you make it sound like firewalls and local DNS intercepting and blocking DNS requests aren't effective. But in practice it is hugely effective.
I hope you can appreciate that DoH is meant to protect against a nefarious intermediary between the device/application and the server it's trying to reach.
The crux of the problem is that the device/application can't tell if the interference is friend or foe.
All the techniques you can legitimately use on your local network, and that network operators have used in the past, can all be used one hop beyond the network you control.
And, sadly, in 2024, most OS vendors are "in the game" of making sure they can 100% control the link and execution environment between themselves and their servers, without interference from the network operators along the way, OR the device owner.
This is silly and not well thought out.
The knowledge of what ip address correlates to some hostname is just data like any other data. There is nothing magically specially different about it, and no way to differentiate it from any other random data that every single process processes.
It's a meaninless wish for something that you can't have, that we all agree would be nice, but is silly to expect.
An app can simply include it's own hard coded list of ips if it wants, or some totally home grown method for resolving a name to a number from any source. It's just key=value like all the infinite other data that every app processes. normal dns and doh are nothing but standards and conveniences, they don't actually control or dictate anything.
You wish apps couldn't do that? So what? Do you also want a pony?
I'd say the same for this unnecessary ad hominem.
This is a basic truth that has no bearing on what I said above.
It's how it worked for personal computing almost since it became popular in the 90s.
Most apps would use the OS set DNS setting. Apps choosing to ignore that and do their own queries is a much more recent thing.
Yes. This also has no bearing on my point.
Wishing apps are not hostile to user intentions is not a fantastical or ignorant desire. Just because apps can be hostile to user intentions does not mean we should accept that as normal or advocate for it.
Because, as an example, as a person responsible for network at my house, I do not want to check whether my child installed another app and check each app one by one ( and that check has to be done and redone every time something changes or someone touches the app ). I want one global setting that says 'Non possumus'.
edit: Unless, naturally, I am no longer an admin and any control I have over my hardware is merely an illusion.
I hate to break it to you, but there is nothing special about hostnames and ips. They are just a tiny bit of key=value data that can be stored or transmitted infinitely different ways. dns and doh are nothing but convenient standards that no one and no app actually has to use.
It doesn't matter how much you might want otherwise. It doesn't matter how important and virtuous the reason you want it is. Even invoking the mighty untouchable power of "my daughter" does not change such a simple fact of life.
It seems like we are arguing for the same outcome. I want to be able to control things within my control. Based on what your wrote, it seems you would support that?
The question has no meaning. "control things within your control" is like a truism, grammatically and logically valid yet says nothing.
The point was that it's pointless to even think in terms of "apps and devices going around my choke point" because there never was a choke point in the first place.
If you want to prevent an app or device on your network from accessing an IP, you must 1: Ensure the app or device has no wifi or cell or any other possible physical connection of it's own that could allow it to reach the internet without going through your router. 2: Block the ip, by ip, in your router, and also any other ip that could serve as a proxy or relay.
It is impossible to know what all those IPs are, so what is possible instead is whitelisting instead of blacklisting.
You could do that, but was it useful or interesting to even say? Didn't you and everyone else already know all that?
<< It is impossible to know what all those IPs are, so what is possible instead is whitelisting instead of blacklisting.
<< The point was that it's pointless to even think in terms of "apps and devices going around my choke point" because there never was a choke point in the first place.
I am not sure why I detect snark. Either it is possible or it is not possible. You argue that we can only assume that things are not communicating with outside world is if there is no network to begin with, which is not completely unreasonable position to take knowing what we know -- cat and mouse gaming being what it is. But even that is slowly becoming less of an option.
<< You could do that, but was it useful or interesting to even say?
Are you suggesting that this conversation is pointless? I don't see it that way. edit: after all, I am participating in this exchange.
The backlash against DoH is that the implementations switch your DNS server without asking to a centralized one which is presumably data mining the queries, default ignoring the one you configured in your operating system or DHCP server.
There is also nothing wrong with using UDP for DNS. And the latency can be better, and in this context that matters. The real problem is that the UDP DNS protocol isn't encrypted. But there is no reason it couldn't be, except that then nobody gets a new source of DNS queries to data mine, which is where the money comes from to push DoH.
ISPs regularly data-mine their users' traffic. Meanwhile, some of the major DoH servers specifically don't. (See, for instance, the deals Mozilla has with their default DoH providers.)
I'm sorry, but this is an argument straight out of the totalitarian's playbook, and I'm going to call you out on it.
Some <bad people> abuse <x>, therefore it is totally justified for us to impose a wholesale replacement of <x> with a solution that we can control centrally. It's for your own safety!
Never mind all the people that don't have data-mining ISP's, and to hell with end-user consent. We don't need that, we're working for the good of everyone. My piety trumps all!
Nothing about the DoH protocol is any more centrally controlled than DNS; that's the point. DoH treats the network as an adversary, and instead ensures the end-user's system can determine what DNS server to talk to and that their traffic can't be spied upon by an intermediary. That part is a feature, just as HTTPS was. (And there were people who complained about the push for universal HTTPS, too.)
Separately from that, there's the issue of how to transition over to DoH, in a world in which many ISPs and networks are hostile. That is the point at which browsers are using the small handful of early-adopter DoH servers and assuming on behalf of some users that they want to use those instead of the servers from their ISP or other network. That part is debatable, and involves tradeoffs between protecting users who don't understand DNS or security and supporting users who do.
DoH gives users the ability to ensure they're talking to the server they think they are, and not get their queries spied on or hijacked. That is the part I'm advocating here: having a protocol that cuts out MITMs and prevents spying on the network traffic. That doesn't solve the problem of needing a trusted DNS server to talk to; it solves the problem of not being sure you're talking to the server you think you are, and not being sure if some part of the network between you and that server is spying on you.
If you have a DNS server you like and trust, whether that's from your ISP or something else entirely, that's great for you! DoH would still be a better protocol to use to talk to that DNS server, rather than the unencrypted DNS protocol.
My ISP doesn’t but the people who run the increasingly centralised internet have a long track record of mining my data for commercial reasons.
I’ll trust my ISP over Google or Cloudflare or Microsoft or DuckDuckGo any day.
I think reasonable people these days don't really trust a provider even if they have explicit contract stating something. Personally, I just trust my ISP a little more than google when it comes to data. But I absolutely do not dream for one moment that they do not want to play with analyzing/monetizing/god knows what else with that data.
You can't possible make that assertion, because all it takes is one NSL and they will log and share it all.
The policy that Mozilla ask providers to follow does not prohibit data-mining the traffic. Providers are requested to not store or share personal information, but any data-mining that removes personal identifiable information are allowed.
For example, accidentally leaked internal network queries from companies are up to grabs. As is market data like what people are querying, how much, when, from where (geographical for example) and to whom, and so on.
The quality of the anonymization of private information are also not guarantied.
Like the one they had that just circled back around to the ISPs that regularly data-mine their users' traffic?: https://arstechnica.com/tech-policy/2020/06/comcast-mozilla-...
Actually they do ask, by querying use-application-dns.net.
The default is not for this to respond in a way that disables changing your DNS server, therefore they're changing the default without asking.
Notice that you could do this the other way: Query a value in the existing (local) DNS or DHCP that not only allows you to enable DoH but also specify which server all the local devices should use. Then if the DNS server chosen by the local administrator/user supports DoH, it could respond by saying so and you could use the protocol without changing your DNS server. But that's not how they did it.
With, say, a proxy app on MacOS, I don't see how they could do this without consent?
It's not that there is no way to turn it off, it's that you have to take affirmative steps to turn it off, so now people are having their queries sent to a central server by default and you have to go out of your way to stop it. And then most people don't even know that it's happening, much less what to do about it.
I assume this is a joke, since DoH3 (DNS over HTTP/3) uses QUIC which is UDP based.
If DNS were running a full session-based encrypted protocol over UDP, like QUIC does, then no one would complain. But running anything that isn't streaming over plain UDP is basically a bad idea.
I feel like you've conflated "UDP" with "unencrypted." This is false; you can perfectly well encrypt data transmitted over UDP, and you can also perfectly well run connections "in the clear" over TCP, which is the thing you generally use instead of UDP. What you don't get with UDP is guaranteed packet delivery, which generally means the application layer is in charge of acknowledgements and retransmits. It's great for game servers where low latency is highly important.
Let me put it like this: for a modern day protocol that should be deployed widely over the internet, the protocol should be expected to have (1) encryption, and (2) session management. Ideally, dedicated protocols should be used for these, for proper separation of concerns, but doing it at the application layer directly can also be acceptable.
Deploying an application protocol that does neither, such as DNS, directly over UDP is a bad idea. If you were to run DNS over DTLS (TLS over UDP), that would be a different beast, and probably ok.
And to clarify, encryption is important to prevent tampering and preserve users's privacy. Session management is important to protect agains redirect attacks with spoofed source IP, or session hijacking.
Okay, but DoH is DNS over HTTPS, which itself runs over TCP/IP, which *does not implement encryption.* (The TLS part of HTTPS is doing that.) You're still mixing the layers here :)
I'm not against the core part of your argument, just against the blaming of a particular choice of transport layer, which is fundamentally irrelevant. Encryption is great. Meanwhile DNS doesn't really need the concept of a session, does it? At the end of the day it's just a single lookup which can very well be fire and forget. That we're encrypting the request (ideally) and also the response (ideally) is no reason to add in loads more complexity.
DoH means running DNS over HTTP over TLS over TCP. TCP does session management, TLS does encryption, HTTP is there just for "plausible deniability".
DoH3 means running DNS over HTTP over QUIC over UDP. Here QUIC does both session management and encryption.
In both cases, we are running a simple application protocol (DNS) over other protocols that handle the Internet-level problems I raised, so all is good.
The problem is with running your application protocol directly and strictly over UDP and nothing else.
And related to sessions, there are two things. For one, in reality today, you typically do a whole host of DNS requests even to load a single site (many common sites have upwards of 20 domains they use, and that's before loading any ads). So having a persistent session to send all of those requests on would not change much, even if it's not technically necessary. Secondly, even if you really want to avoid sessions, you then still need some other mechanism to prevent source IP spoofing.
Any protocol which allows a host to send a small request to a server and cause that server to send a large response to the src IP of that request is a major problem for the health of the internet. Requiring a handshake to solve this is one simple way to avoid the problem entirely. DNS implementations have had to find all sorts of other mitigations to address this (I believe they now typically don't allow responses more than a factor of 1.something larger than the request, or something like that? Which of course brings in all sorts of extra problems and unnecessary traffic)
Yes, and the person you're replying mentioned that it was perfectly possible to encrypt data over UDP. Presumably they meant DTLS. So what's your concern?
I was explaining that saying "don't run DNS over UDP" is a completely different thing than saying "don't run DNS over anything that ultimately runs over UDP". It's not that I don't know you can encrypt things over UDP, it's that I wasn't talking about that.
A caveat of encrypted DNS is that it has to be bootstrapped via traditional, unencrypted DNS or via a well-known set of IPs. Currently, most clients using DoH/DoT use one of a small handful of providers. Cloudflare, Google, Quad9, etc. A motivated government could block those endpoints pretty easily.
Of course, a client using encrypted DNS could just refuse to work when encryption is blocked, rather than falling back to traditional DNS. But that could mean the client is unusable in the country implementing the block.
This sort of reminds me of when Kazakhstan announced they were going to MITM all TLS sessions within the country, and all citizens would need to manually install a root cert. Google, Apple, and Mozilla chose to completely block their root cert, so it would be unusable even if users chose to go along with it. https://en.wikipedia.org/wiki/Kazakhstan_man-in-the-middle_a... Seems like the browser devs won that political standoff, but would they fight the same battle if DoH/DoT was blocked?
A caveat of encrypted DNS is that it has to be bootstrapped via traditional, unencrypted DNS or via a well-known set of IPs. Currently, most clients using DoH/DoT use one of a small handful of providers. Cloudflare, Google, Quad9, etc. A motivated government could block those endpoints pretty easily.
not if DNS is hosted on the same servers as eg google search itself. then they would have to block google search in order to block DNS.
…or use higher-level packet analysis to filter DoH.
With HTTP/3 there isn't much higher level packet analysis to do between anything useful in the headers being encrypted and the session being reused. All you see is there is a 443 UDP session to a Google server and encrypted packets keep getting sent back and forth... which looks exactly like any other HTTP/3 session to a Google server.
I think the weak points are wholly untechnical e.g. Google would often give in to protect the $$$ they make in a region.
Packet size (i forget if http/3 does padding) and packet rates are still available, dns looks a lot different than most http content.
In terms of packet size, DNS (DoH) doesn’t really look any different to an XHR request.
Request maybe, DoH responses are probably way shorter than anything else though.
That kind of DPI is computationally expensive to the point China doesn't even do it much.
OMG, they very much do. It is not on 100% of the traffic but at any given time a more then smaller % is subject to DPI.
Not anymore and mainland Chinese manufacturers sell them on in large numbers to autocratic governments.
Such devices have a pretty simple architecture: the highly performant data plane where DPI is implemented in the hardware (using either ASIC's or FPGA's – don't have enough information), and the control plane. The control plane comes with a SDK of sorts that DPI appliance users can use to tailor the appliance to their environment and that is used to «refine» the data plane behaviour, i.e. sending down / updating DPI pattern matching / processing rules.
Then they will block Google Search and blame it on Google ?
This is the way. Few governments have the resources to play cat and mouse with OS or browser devs. Just look at the fuss over manifest v3, it shouldn’t be a big deal - just fork chromium and patch manifest v2 back in again - but it is because there’s no “just patching” chromium, it’s like a train.
If we make sure clients support proxies what are they going to do about all the proxies that may allow the DoH server list and may be the only way to do something else?
Unencrypted DNS also has to be bootstrapped by a well-known set of IPs. None of the current DNS propagation system would work if it wasn't for the hardcoded IPs for the root DNS servers at *.root-servers.net.
And, of course, end-user devices still need an IP to query for DNS, it's just that it's almost always supplied automatically via DHCP or similar.
DoH won't solve redirects. DoH only gets you to a secure query, it won't help you if the government decides to give you a falsified query. For that you'll need DNSSec, which maintains a cryptographic chain of authenticity to the root DNS servers. And DNSSec is even more rare than DoH.
DoH will prevent government from hijacking your query in the first place. These blockades are only possible because of DNS being clear text and suceptible to MITM
That's one level of security, but even for DoH, it's possible for entities to attack and control an HTTPS server, returning falsified DNS queries, and now the antigovernment.com website you logged in to talk about anti-government politics is actually run by government. The only way to prevent that is via DNSsec to make sure that antigovernment.com goes to a real antigovernment.com server.
Wait what do you mean? They can have an HTTPS server and MITM, but how can they get a certificate for the DoH server I use?
They only need a certificate signed by an authority trusted by your resolver. And, unlike for the website itself, your browser does not show certificate information for the DoH server.
DoH also does not solve the problem of where the DNS server you use gets its information from: A government can compromise the other side as well.
So, like, you are assuming someone using a resolver that ignores the certificate chain of trust, as an evidence that DoH is not useful?
Do your program language _show_ you the certificate information when you use an http library to connect to an HTTPS service?
Sure the other end of the DNS query may not be encrypted, but I can easily decide which government to trust, and run my DoH server there.
It doesn't show it, but I expect it would put up an error message if the DoH server's cert is invalid.
This makes no sense whatsoever.
If the government can transparently MITM your HTTPS connections with the DoH server, they can just as well MITM your connection to the real antigovernment.com server regardless of what DNS you use. And in fact, if they can't MITM your connection to the real antigovernment.com, they also can't trick you to talk to their fake antigovernment.com regardless of intercepting your DNS: you will connect to the attacker IP, the attacker IP will give you a bogus certificate, your browser will refuse to connect.
DNSSec is entirely useless here. The government has two goals here: block you from accessing certain sites, and perhaps prosecute you for the attempt. DNSSec does exactly nothing to help against either of these , even if perfectly deployed.
DNSSec can help protect from fraudsters or others that might try to transparently direct you to a different site than the one you wanted to access. But the government here has no intention of serving you a fake porn site, they want to stop you accessing porn and log the fact that you were trying to access it.
https://dl.acm.org/doi/10.1145/358198.358210
I don't really trust many DNSes and neither do many yet we all have few choices
The lack of MitM isn't much comfort
Neither are guarantees of the chain of trust
DoH uses HTTPS; it solves redirects because you can use a trusted server, and not have the request intercepted and the response spoofed.
DoH helps us against governments, but doesn't help us against advertisers, i.e. what stops Google or an app maker talking to their own DNS endpoint via DoH and avoiding local measures to block malware and tracking.
DoH is a double edged thing, advertisers are a more present and pervasive threat to most than their own government
Community based FOSS OSes/distros stop all this and avoiding the corporate SW/services.
How do I install a Foss OS to my TV or my kid's tablet? And without breaking DRM attestation?
Pinetab2 as a tablet, or some x86_64 tablet of which there are many.
For TV, use it as a dumb display for some FOSS TV box, running something like libreelec.
As for DRM attestation, that's not the responsibility of anyone but the DRM vendor, so ask them.
If you use services requiring DRM, you are one of the bad actors, why should we care about what you think ?
If by most people you mean most people globally, governments are absolutely a bigger threat; only a minority of the world's population live in countries with benevolent governments who don't censor the internet to hide the government's misdeeds.
don’t forget the us federal government paid twitter and Facebook to remove speech it didn’t like (speech that turned out to be true).
> DoH helps us against governments
And bad ISPs⁰.
And a small subset of MitM attacks.
> advertisers are a more present and pervasive threat to most than their own government
That is true for me¹ but I'd not agree with "most" globally. And while stalky corporates and the people who will get hold of my data subsequently due to lax security are my main concern, there are other ways to mitigate them. Less convenient ways, sure, and I loose a security-in-depth step of ashtray using them anyway, but I consider that inconvenience for me² to be less of an issue than the more serious problems DoH might mitigate for others.
----
[0] some people don't have a simple "just go elsewhere" option
[1] relatively speaking: I don't consider my government that trustworthy, and will do so even less in future if the Tories get back in without major changes in their moral core, and I'm sure many Americans feel similarly if they consider the implications of Project2025.
[2] both as an end user wanting to avoid commercial stalking and as someone who sometimes handles infrastructure for a B2B company that uses DNS based measures as part of the security theater we must present to clients when bidding for their patronage
An ISP could effectively bypass DoH. Block outgoing requests to IP addresses that the ISP has not whitelisted, and automatically whitelist IP addresses that were obtained from non-DoH DNS requests.
You could argue against seatbelts the same way: seatbelts can cause abrasion of the skin during everyday driving, which is a more present and pervasive threat to most than car crashes.
In both instances it turns out that the difference in magnitude of those threats makes the direct comparison misleading.
I've never heard of seatbelt skin abrasion, but car crashes are an exceptionally commom danger.
As an infrasec person, DoH is great because we can config manage all the corp devices to use DoH servers run by the company whether not a device is on VPN. Good visibility into what devices are looking up, easy internal domains, and ensuring malware domains are blocked on and off network.
At least the companies I’ve been working for have a lot more laptops at coffee shops and weworks, and probably not on a VPN half the time either. DoH has been a way bigger win than a hassle for me.
how would you ever get online at a coffee shop? Almost all of this use a captive portal that redirects DNS to some internal webpage making you click a button that says "I agree to your completely absurd terms and conditions"
I can use a mobile hotspot on my phone basically everywhere I go. Public Wifi is most often garbage throughput compared to 5g.
A good implementation of DoH/DoT would use regular DNS in these situations.
I have found that fewer places seem to be doing captive portals and are just going back to open wifi or maybe a well-posted password. Maybe they are realizing there's not a lot of value to it as almost all browser traffic is encrypted these days.
If you have any Windows devices they are leaking DNS requests no matter the setup as long as they are getting DNS servers from DHCP that aren't yours.
Even if DNS is redirected, where DNS lookup request goes to next depends on the next hop, which is – for the prevailing majority of the internet users – the ISP.
Deep packet inspection hardware appliances have proliferated in their numbers in recent years, they are cheap, the hardware is highly performant, and they are capable of the highly sustained throughput. Redirecting DNS queries in UDP port 53 to any other destination of choice is what they can do without blinking an eye (if they had one). Or dropping / blackholing it.
Only a VPN tunnel can get through, however modern DPI appliances can also scan for VPN and VPN-like signatures in the traffic and drop those, too. The only viable and guaranteed to work solution to resist the tampering with the traffic is a VPN tunnel wrapped into a Shadow Socks tunnel that obfuscates traffic signatures and constantly changes ports it operates on to avoid detection.
DoH is sufficient to mitigate DPI.
Widely used DoH servers operate on fixed IP addresses (v4 and v6), connections to which can be dropped / blackholed, which is what people from at least the UK and Malaysia are reporting. DPI is not even required.
Co-incidentally Mullvad recently mentioned they're fighting back
https://mullvad.net/en/blog/introducing-defense-against-ai-g...
And now available for macOS and Linux https://mullvad.net/en/blog/defense-against-ai-guided-traffi...
Then transparently redirect the DNS request from all your machines at home to your own DNS resolver (so that you're in control of what gets resolved and what doesn't, like malware, phishing sites, porn so that kids don't get to see that, etc.) and have your own DNS resolver use DoH.
But asking for browsers to "make DoH ubiquitous" (they would force DoH and DoH only) is not a good thing. It also probably would clash with corporate policies, so it'd make the browser picking that path unusable in corporate settings (leaving the corporate market to competitor browsers).