3 ms·

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

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.
- eridius 8y ago
  Most users will just happen to be dependent on cloud providers for DoH not because of anything inherent to DoH, but because at the moment only cloud providers are offering DoH-enabled resolvers. If you don't like this, then instead of decrying the usage of DoH, you should be pushing for more DNS providers to offer DoH. I do agree that pushing DNS functionality into apps instead of the OS level is suboptimal, and I certainly hope that, if Firefox proves that DoH works well, it will be adopted by the major OS's (along with a way to query the OS resolver to check if it's using DoH or not) so that all apps can benefit from it instead of just web browsers that reimplement DNS. Of course, IIRC Chrome at least (not sure about Firefox) has already been implementing DNS resolution itself for a long time rather than relying on the OS resolver, so the idea of a web browser doing DNS directly instead of relying on the OS is not a new one. I'm not sure why Chrome does this though.

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.

eridius 8y ago
Most users will just happen to be dependent on cloud providers for DoH not because of anything inherent to DoH, but because at the moment only cloud providers are offering DoH-enabled resolvers. If you don't like this, then instead of decrying the usage of DoH, you should be pushing for more DNS providers to offer DoH. I do agree that pushing DNS functionality into apps instead of the OS level is suboptimal, and I certainly hope that, if Firefox proves that DoH works well, it will be adopted by the major OS's (along with a way to query the OS resolver to check if it's using DoH or not) so that all apps can benefit from it instead of just web browsers that reimplement DNS. Of course, IIRC Chrome at least (not sure about Firefox) has already been implementing DNS resolution itself for a long time rather than relying on the OS resolver, so the idea of a web browser doing DNS directly instead of relying on the OS is not a new one. I'm not sure why Chrome does this though.