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.
You can't possible make that assertion, because all it takes is one NSL and they will log and share it all.
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-...
I’ll trust my ISP over Google or Cloudflare or Microsoft or DuckDuckGo any day.
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!
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.
With, say, a proxy app on MacOS, I don't see how they could do this without consent?
Actually they do ask, by querying use-application-dns.net.
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.
I assume this is a joke, since DoH3 (DNS over HTTP/3) uses QUIC which is UDP based.
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.
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.
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?
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.
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.
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.
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).
> 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
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.
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.
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.
> 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.
This is a basic truth that has no bearing on what I said above.
> It's a meaninless wish for something that you can't have, that we all agree would be nice, but is silly to expect.
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.
> 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.
Yes. This also has no bearing on my point.
> You wish apps couldn't do that? So what? Do you also want a pony?
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.
edit: Unless, naturally, I am no longer an admin and any control I have over my hardware is merely an illusion.
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.
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?
<< 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.
Sounded more like a kneejerk reaction and a meme for something that's an improvement. UDP at this day and age? Come on