4 ms·

We need something to encrypt and authenticate DNS, but that exists in DNSCurve. The problem with it is that it doesn't try to hide what it is, so an adversarial

by zrm 7y ago

We need something to encrypt and authenticate DNS, but that exists in DNSCurve. The problem with it is that it doesn't try to hide what it is, so an adversarial middlebox can detect and block it to try to force you to use their own DNS. DoH is an evolutionary response to that, because it looks like HTTPS to Cloudflare, which is difficult to reject. And that's terrible for a lot of reasons (inefficiency, complexity, centralization), but it solves the local interference problem. Which means that's what we're unfortunately going to end up with unless we can solve the interference problem another way, i.e. make intermediaries understand that they're going to lose anyway and it's better to allow unmolested UDP DNS/DNSCurve to the endpoint's choice of recursive resolvers than to have everything using DoH to Cloudflare.

teddyh 7y ago
There are two available courses of action. Option one: We embrace something like DoH in order to avoid any possibility of blocking and detection. But you then have no simple way to back out from centralization if/when centralization (almost certainly, IMHO) slowly becomes a problem. Monopolies and oligopolies are hard to break once formed, and absolute power corrupts absolutely. Option two: We use DNS like always to avoid problems with centralization, and adopt a secure DNS protocol to avoid spoofing and unauthorized monitoring. If we do this latter thing, and detection and blocking does become a problem (and it might), we can always add some additional layer of security, like HTTPS tunneling, on top, which avoids it. We could even, if it became absolutely necessary, centralize after the fact; but this way, we can avoid it until it would become necessary. I would prefer not to centralize things in advance, just in case a certain problem develops. I would instead prefer to keep it de-centralized as long as possible, and solve individual problems as they actually occur. I would also prefer DNSSEC and DoT over DNSCurve, and I would suggest IPsec with opportunistic encryption to be a more pure goal than to tunnel everything over HTTPS, but my preferences in protocols are not important to any of these points, and we don’t need to argue about that.
- zrm 7y ago
  We're already there. There are already ISPs in some parts of the world redirecting DNS queries to any DNS server to the ISP's DNS server, which gives invalid responses to queries that authenticate the DNS server (DNSCurve) or invalid responses to queries it can read and wants to block (DNSSEC), either of which is an effective denial of service attack. Which drives adoption of ugly DoH. The root problem where the centralization comes in (because you could actually do DoH to something that isn't Cloudflare), is that you need to trust someone to faithfully and completely answer all of your DNS queries without dropping any of them or sending invalid responses for queries they don't like. That used to be your ISP, and we had a decentralized solution as long as the ISPs would faithfully answer all queries, but what happens when they don't? You need someone else. "Let everyone choose for themselves" is a theoretical answer, but in practice the average person doesn't know anybody who runs a public recursive DNS server, and Google and Cloudflare are easy and "free", so everybody will end up on them. To prevent that we need ISPs to stop interfering with DNS.

by zrm 7y ago

teddyh 7y ago

There are two available courses of action. Option one: We embrace something like DoH in order to avoid any possibility of blocking and detection. But you then have no simple way to back out from centralization if/when centralization (almost certainly, IMHO) slowly becomes a problem. Monopolies and oligopolies are hard to break once formed, and absolute power corrupts absolutely. Option two: We use DNS like always to avoid problems with centralization, and adopt a secure DNS protocol to avoid spoofing and unauthorized monitoring. If we do this latter thing, and detection and blocking does become a problem (and it might), we can always add some additional layer of security, like HTTPS tunneling, on top, which avoids it. We could even, if it became absolutely necessary, centralize after the fact; but this way, we can avoid it until it would become necessary. I would prefer not to centralize things in advance, just in case a certain problem develops. I would instead prefer to keep it de-centralized as long as possible, and solve individual problems as they actually occur. I would also prefer DNSSEC and DoT over DNSCurve, and I would suggest IPsec with opportunistic encryption to be a more pure goal than to tunnel everything over HTTPS, but my preferences in protocols are not important to any of these points, and we don’t need to argue about that.

zrm 7y ago
We're already there. There are already ISPs in some parts of the world redirecting DNS queries to any DNS server to the ISP's DNS server, which gives invalid responses to queries that authenticate the DNS server (DNSCurve) or invalid responses to queries it can read and wants to block (DNSSEC), either of which is an effective denial of service attack. Which drives adoption of ugly DoH. The root problem where the centralization comes in (because you could actually do DoH to something that isn't Cloudflare), is that you need to trust someone to faithfully and completely answer all of your DNS queries without dropping any of them or sending invalid responses for queries they don't like. That used to be your ISP, and we had a decentralized solution as long as the ISPs would faithfully answer all queries, but what happens when they don't? You need someone else. "Let everyone choose for themselves" is a theoretical answer, but in practice the average person doesn't know anybody who runs a public recursive DNS server, and Google and Cloudflare are easy and "free", so everybody will end up on them. To prevent that we need ISPs to stop interfering with DNS.