3 ms·

If you don't trust your network why don't you install a DNS stub resolver that tunnels to some external resolver that you trust and then set the OS to use local

If you don't trust your network why don't you install a DNS stub resolver that tunnels to some external resolver that you trust and then set the OS to use localhost? Don't push things into applications and make things more difficult for everyone else when you can secure your own computer.

Spivak 8y ago
> install a DNS stub resolver that tunnels to some external resolver that you trust. Because the we're dealing with computers as they actually exist and are configured. And within epsilon every personal computer on the planet is configured to trust DHCP and set their DNS servers to whatever is offered. So we're in a situation where these particular applications also don't really trust the OS to a certain extent.
- the8472 8y ago
  You have that backwards. It's applications that are less than trustworthy. That's why we try to sandbox them. As for the DHCP part, if you're on a public network you should only trust it as far as you need it to bootstrap your tunnel over which you can then finally contact a trusted resolver. OS resolver -> a single thing you need to secure every app uses its own resolver -> complete mess which makes it harder to ensure privacy of your traffic
  - Spivak 8y ago
    Browsers don't trust the OS to provide secure private name resolution. And they really shouldn't when every OS just blindly takes whatever is offered via DHCP. I absolutely agree that DNS should be a system-level concern rather than app-level. But today, right now, for computers as they are and will continue to be for the foreseeable future this is a huge improvement. Browsers being the app that handles basically all of our sensitive information I think have earned the exception.
    - the8472 8y ago
      I don't think this is the proper approach. Once it's in browsers it will also be in electron applications. And those may update less frequently. Now you have balkanized implementations of custom DNS stub resolvers using different remote endpoints. That makes security updates more difficult, network issues more difficult to debug and so on. Doing it properly would involve securing the system, once. This could be easily done by installing a DoH stub resolver service and then pointing the system config to localhost.

Spivak 8y ago

> install a DNS stub resolver that tunnels to some external resolver that you trust. Because the we're dealing with computers as they actually exist and are configured. And within epsilon every personal computer on the planet is configured to trust DHCP and set their DNS servers to whatever is offered. So we're in a situation where these particular applications also don't really trust the OS to a certain extent.

the8472 8y ago
You have that backwards. It's applications that are less than trustworthy. That's why we try to sandbox them. As for the DHCP part, if you're on a public network you should only trust it as far as you need it to bootstrap your tunnel over which you can then finally contact a trusted resolver. OS resolver -> a single thing you need to secure every app uses its own resolver -> complete mess which makes it harder to ensure privacy of your traffic
- Spivak 8y ago
  Browsers don't trust the OS to provide secure private name resolution. And they really shouldn't when every OS just blindly takes whatever is offered via DHCP. I absolutely agree that DNS should be a system-level concern rather than app-level. But today, right now, for computers as they are and will continue to be for the foreseeable future this is a huge improvement. Browsers being the app that handles basically all of our sensitive information I think have earned the exception.
  - the8472 8y ago
    I don't think this is the proper approach. Once it's in browsers it will also be in electron applications. And those may update less frequently. Now you have balkanized implementations of custom DNS stub resolvers using different remote endpoints. That makes security updates more difficult, network issues more difficult to debug and so on. Doing it properly would involve securing the system, once. This could be easily done by installing a DoH stub resolver service and then pointing the system config to localhost.