3 ms·
Adversarial networks are not the common case. On the majority of networks you can send a plaintext UDP DNS query to 8.8.8.8 or 1.1.1.1 and nothing will actually
by zrm 7y ago
Adversarial networks are not the common case. On the majority of networks you can send a plaintext UDP DNS query to 8.8.8.8 or 1.1.1.1 and nothing will actually interfere with it in practice.
Adversarial networks exist, which is why something like DoH or DNSCurve should be used in favor of unauthenticated DNS over the internet, but the real issue here is independent of which DNS protocol is used -- it's how the recursive resolver is chosen.
The canonical answer to that is to use DHCP or similar to distribute the resolver that should be used for the local network, and allow the user to manually configure a different one in any case where that one is untrustworthy. DHCP is the ordinary method of endpoint control for configuring the endpoint's DNS server.
The endpoint shouldn't have to be exposed to manual configuration or give up even more control over other unrelated settings by adding their device to something like a third party Active Directory domain just to be able to plug into a local network and have local name resolution work.
- tptacek 7y agoYour threat model isn't the set of actors currently attacking you, but rather those actors who can and might attack you in the future. Your ISP is certainly adversarial in any sane threat model.
- zrm 7y agoAren't you the one usually telling everyone that DNSSEC is useless even though it solves the same problem, e.g. because the server can be verified with TLS instead? If the DNS attack is nothing more than a denial of service then it seems completely reasonable to wait until the attack is actually observed before applying a mitigation (third party DNS) that can have problematic side effects. Especially when the mitigation can be made as simple as a single checkbox in the browser. And what makes Cloudflare any more trustworthy than the average ISP? Isn't that just switching the user's resolver from the network they explicitly chose to connect to, to a centralized third party that they didn't?
- tptacek 7y agoDNSSEC doesn't solve any practical problem, but does have the effect of escrowing TLS keys to world governments. DoH solves an immediate problem, which is that ISPs (and other entities) passively monitor DNS traffic to collect intelligence on network users. DNSSEC does nothing about this problem. You don't have to use Cloud Flare for DoH, and I wouldn't.
- zrm 7y ago> DoH solves an immediate problem, which is that ISPs (and other entities) passively monitor DNS traffic to collect intelligence on network users. DNSSEC does nothing about this problem. That's assuming the DoH provider isn't monitoring queries either. Doesn't Cloudflare have a deal with APNIC to do exactly that? > You don't have to use Cloud Flare for DoH, and I wouldn't. That's the point -- the problem isn't that DoH exists, it's when an application changes your DNS provider to Cloudflare by default instead of using the one you have in your system configuration.
- tptacek 7y agoYou can trivially boot up your own DoH provider if you don't trust any of the existing ones. It's hard to imagine a protocol that would improve this situation: "supported by major vendors, and free to use for everyone". I won't use Firefox to begin with (I'll reconsider when it's mostly Rust!), and so don't care so much about how Mozilla is handling this. Personally, I wouldn't touch Cloud Flare with a 10 foot pole. But that's not what I'm commenting about; I'm talking about DoH itself, which is an unalloyed good thing, which you can tell in part by the fact that the knives are out for it.