3 ms·

If your browser is talking to a DNS resolver wired to your OS, that doesn't change what any upstream network observer sees, since they can observe DNS requests

If your browser is talking to a DNS resolver wired to your OS, that doesn't change what any upstream network observer sees, since they can observe DNS requests generated by your OS-level DNS resolver exactly as they would observe DNS requests generated by your browser. DOH isn't about trust. It's about preventing network observers from figuring out what sites you visit by observing the DNS requests you make.

the8472 8y ago
I am perfectly capable of having my DNS resolver use a different, encrypted route than the HTTPS traffic. This is not mozilla's decision to make.
tialaramex 8y ago
Not _only_ about trust. One of the things DoH gets you for free is that it means that your ISP doesn't get to touch DNS requests, which was not true previously. You can get Internet service from whatever bunch of money-grabbing assholes are available where you live, and get DNS from somebody else without that being tampered with since it's encrypted on the wire. You do still have to trust the DoH provider (outside of DNSSEC). In the UK for example, the current government proposals for yet more Internet censorship assume that they can "just" order ISPs to censor DNS. This, their white paper says, is relatively cheap and so ISPs might even be willing to do it at no extra cost, which is convenient for a supposedly "small government / low tax" party that keeps thinking of expensive ways to enact their socially regressive agenda... But DoH and indeed all the other D-PRIVE proposals kill that, to censor users with D-PRIVE you're going to have to operate a bunch of IP layer stuff, maybe even try to do deep packet inspection, which TLS 1.3 already made problematic and eSNI skewers thoroughly. So there's a good chance this sort of thing for _ordinary_ users (the white paper already acknowledges that yes, people can install Tor and it can't do anything about that) makes government censorship so difficult and thus expensive as to be economically unpalatable. "Won't somebody think of the children" tastes much better when it doesn't come with a 5% tax increase to pay for it...
- xg15 8y ago
  Conventiently, the same will also apply to me trying to block apps from talking over the network with things they should not talk to.
  - Ajedi32 8y ago
    You could always point your DNS at your own DNS-over-HTTPS server, then configure that server to forward requests over an encrypted connection to another DNS-over-HTTPS server. Don't know if there are any tools available right now that will do that for you, but there's no technical reason why it isn't possible.
    - xg15 8y ago
      I think the problem will be apps with a DoH service hardwired. There wouldn't be anything for me to point anywhere short of patching the app. Yes, apps could theoretically already do this today if the developers are willing to run their own endpoints. However, my guess is this will become vastly easier to do when there are already public DoH endpoints available to connect to.
vetinari 8y ago
There isn't anything that would prevent the local resolver to talk upstream using DoH. Same privacy, minus cloud companies that try to insert themselves as middleman.
- eridius 8y ago
  DOH does not rely on cloud companies. The requirement for DOH has nothing to do with cloud companies "try[ing] to insert themselves as middleman". You certainly could argue that ESNI should be used even if DNS isn't done over DOH, in case you trust the network path to your recursive resolver and you trust the recursive resolver itself to be using DOH, but that also has nothing to do with cloud companies. I admit I'm not sure why ESNI requires DOH (it's not particularly useful without DOH, but that's not an argument to disable it); my guess is simply due to the additional resource usage necessary to process ESNI requests, and so Firefox doesn't want to put this additional load on the server if there's no practical benefit to doing so. Ideally, using an OS-level resolver would have a way to tell the browser that the recursive resolution was encrypted (whether via DOH or something else it doesn't really matter), but I'm not aware of any way to do that at the moment.
  - the8472 8y ago
    > Ideally, using an OS-level resolver would have a way to tell the browser that the recursive resolution was encrypted A simple flag to configure this would have done the job. I don't like how browsers are pretending that they have security needs that are special compared to any other application and thus need to pull in the whole network stack and bypass the OS on everything. It causes duplicate effort if you want to secure your whole network instead of only the browser. It also limits technology choice. I'm forced to use DoH even though there are other options.
  - vetinari 8y ago
    DoH by itself does not, but the way it is getting implemented, most users will just happen to be dependent on them. That's why I wrote that. Instead of pushing this functionality into OS resolvers and standalone resolvers used by networks, it is being pushed into commonly used applications, with cloud companies providing the other end by default. ESNI doesn't require DoH, but there's no point of using it without one, if your network can check the DNS records you are asking for, and then check the ecrypted SNI against it (it will have the same key you are using to encrypt, so it can do the same and match). Some resolvers (systemd-resolved, ducks and hides) do use custom API to attach properties to responses. That was the only way to get DNSSEC status, so it can be reused to indicate upstream protocol too. However, not many applications use that, they rely on standard gethostbyname(), which doesn't provide anything similar.

the8472 8y ago

I am perfectly capable of having my DNS resolver use a different, encrypted route than the HTTPS traffic. This is not mozilla's decision to make.

tialaramex 8y ago

Not _only_ about trust. One of the things DoH gets you for free is that it means that your ISP doesn't get to touch DNS requests, which was not true previously. You can get Internet service from whatever bunch of money-grabbing assholes are available where you live, and get DNS from somebody else without that being tampered with since it's encrypted on the wire. You do still have to trust the DoH provider (outside of DNSSEC). In the UK for example, the current government proposals for yet more Internet censorship assume that they can "just" order ISPs to censor DNS. This, their white paper says, is relatively cheap and so ISPs might even be willing to do it at no extra cost, which is convenient for a supposedly "small government / low tax" party that keeps thinking of expensive ways to enact their socially regressive agenda... But DoH and indeed all the other D-PRIVE proposals kill that, to censor users with D-PRIVE you're going to have to operate a bunch of IP layer stuff, maybe even try to do deep packet inspection, which TLS 1.3 already made problematic and eSNI skewers thoroughly. So there's a good chance this sort of thing for _ordinary_ users (the white paper already acknowledges that yes, people can install Tor and it can't do anything about that) makes government censorship so difficult and thus expensive as to be economically unpalatable. "Won't somebody think of the children" tastes much better when it doesn't come with a 5% tax increase to pay for it...

xg15 8y ago
Conventiently, the same will also apply to me trying to block apps from talking over the network with things they should not talk to.
- Ajedi32 8y ago
  You could always point your DNS at your own DNS-over-HTTPS server, then configure that server to forward requests over an encrypted connection to another DNS-over-HTTPS server. Don't know if there are any tools available right now that will do that for you, but there's no technical reason why it isn't possible.
  - xg15 8y ago
    I think the problem will be apps with a DoH service hardwired. There wouldn't be anything for me to point anywhere short of patching the app. Yes, apps could theoretically already do this today if the developers are willing to run their own endpoints. However, my guess is this will become vastly easier to do when there are already public DoH endpoints available to connect to.

vetinari 8y ago

There isn't anything that would prevent the local resolver to talk upstream using DoH. Same privacy, minus cloud companies that try to insert themselves as middleman.

eridius 8y ago
DOH does not rely on cloud companies. The requirement for DOH has nothing to do with cloud companies "try[ing] to insert themselves as middleman". You certainly could argue that ESNI should be used even if DNS isn't done over DOH, in case you trust the network path to your recursive resolver and you trust the recursive resolver itself to be using DOH, but that also has nothing to do with cloud companies. I admit I'm not sure why ESNI requires DOH (it's not particularly useful without DOH, but that's not an argument to disable it); my guess is simply due to the additional resource usage necessary to process ESNI requests, and so Firefox doesn't want to put this additional load on the server if there's no practical benefit to doing so. Ideally, using an OS-level resolver would have a way to tell the browser that the recursive resolution was encrypted (whether via DOH or something else it doesn't really matter), but I'm not aware of any way to do that at the moment.
- the8472 8y ago
  > Ideally, using an OS-level resolver would have a way to tell the browser that the recursive resolution was encrypted A simple flag to configure this would have done the job. I don't like how browsers are pretending that they have security needs that are special compared to any other application and thus need to pull in the whole network stack and bypass the OS on everything. It causes duplicate effort if you want to secure your whole network instead of only the browser. It also limits technology choice. I'm forced to use DoH even though there are other options.
- vetinari 8y ago
  DoH by itself does not, but the way it is getting implemented, most users will just happen to be dependent on them. That's why I wrote that. Instead of pushing this functionality into OS resolvers and standalone resolvers used by networks, it is being pushed into commonly used applications, with cloud companies providing the other end by default. ESNI doesn't require DoH, but there's no point of using it without one, if your network can check the DNS records you are asking for, and then check the ecrypted SNI against it (it will have the same key you are using to encrypt, so it can do the same and match). Some resolvers (systemd-resolved, ducks and hides) do use custom API to attach properties to responses. That was the only way to get DNSSEC status, so it can be reused to indicate upstream protocol too. However, not many applications use that, they rely on standard gethostbyname(), which doesn't provide anything similar.