Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Big DNS Privacy Debate at FOSDEM

blog.powerdns.com

Post reply on HN
Print view View original

21–30 of 63 posts

Re: The Big DNS Privacy Debate at FOSDEM

#21

Post by teddyh »

Encryption usually solves three problems:

1. Authenticity of data; i.e. fixing DNS spoofing.

2. Privacy

3. Censorship

Problem 1 is fixed today by DNSSEC.

The best solution for problem 1, 2 and 3 would be if IPsec had a working and deployed PKI, so IPsec could be used for all IP-based traffic, and nobody had to worry about encryption on any layer above that.

Lacking that, the next best thing for problem 2 would be for DNS to use TLS and/or DTLS, and there is a standard for DNS over TLS (DoT), which makes perfect sense to use today between resolvers and authoritative servers, and between master servers and slave servers. However, this does not solve problem 3, since DoT uses a separate port and can be trivially downgraded by a MITM to use old non-TLS DNS. In theory, this could be fixed by something similar to how DANE solves the same problem for SMTP, in that a separate channel can be used to indicate not to allow protocol downgrades.

But, this problem of censorship is in practice, today, primarily an issue between the client and the resolver. If that traffic can use DNS-over-HTTPS, this would avoid problem 3 as well.

Note that none of this requires any centralization of resolvers, and is technically completely tangential. The problem of centralized resolvers existed since centralized resolvers first appeared; witness the prevalence of using Google’s 8.8.8.8, etc. This is a huge problem independent of DNS-over-HTTPS.

The connection, as far as I can tell, between DoH and centralization is that browsers want to fix as many as possible of problems 1-3, and using a centralized provider of DNS-over-HTTPS does that, at the expense of centralization and a single point of failure for problem 1-3. This is of course a terrible idea. But I can certainly see why browser vendors are attracted to the idea, bad though it may be.

Re: The Big DNS Privacy Debate at FOSDEM

#22

Post by rini17 »

Is the research of homomorphic encryption far enough that it's practical to implement for DNS? The server would accept DNS queries using such cryptographic algorithms on encrypted database, that he nor anybody else can't say which record was queried. Only the client.

Re: The Big DNS Privacy Debate at FOSDEM

#23

Post by icebraining »

kardos wrote: post #9

Potential workarounds: 1. Round Robin your DoH requests across several providers. Eg, if CloudFlare sees one quarter of your DNS requests it's less revealing then if they see all of them. 2. DNS proxies. Sort of like a VPN for the DNS requests such that they're aggregated to one source IP before being passed to the DoH provider. Done at the ISP level? Or some other arrangement. The VPN here would not be privy to the…

1) seems unlikely; a 25% sample is probably quite representative.

2) that's essentially what a typical DNS provider like Cloudflare or Google DNS is: they proxy your requests back to the authoritative DNS servers, then return the response to you.

Re: The Big DNS Privacy Debate at FOSDEM

#24

Post by zzzcpan »

criddell wrote: post #17
scame wrote: post #4

As they say, if it's free, then you're the product. I (as a European) have much more confidence in my ISP to guarantee my privacy than in a company which mostly makes money out of advertisement.

Your ISP doesn't sell user data? I'm in the US and feel the exact opposite. I trust Google and CloudFlare far more than AT&T or Verizon.

With these proposals you still have to trust your ISP in addition to trusting Google and Cloudflare. You can avoid trusting all three, your ISP, Google, Cloudflare by trusting instead a single VPN provider of your choice (or a hosting provider where you can run your own VPN server).

Re: The Big DNS Privacy Debate at FOSDEM

#25

Post by icebraining »

gsich wrote: post #19
detaro wrote: post #16

Earlier quoted context omitted.

Some would argue "still UDP based" is objectively worse, since it can be blocked. I don't think DNSCrypt is better for caching, doesn't it just protect one "leg" from a client (which can be a local cache) to a resolver (which also can be a cache) just like DoH? Similarly for pinning keys (although I think DNSCrypt made exchanging keys easier).

Major advantage is the latency. TCP needs 3 trips, TLS an additional 4. With dnscrypt you have one request and one response. Then again, Cloudflare and Quad9 terminate the connection almost instantly after finishing your request. Tested this with DoT though. (stubby with high timeout set)

Are you sure that's not a problem with the client? It seems Cloudflare supports leaving the connection open just fine (at least using the cloudflared client).

Re: The Big DNS Privacy Debate at FOSDEM

#26

Post by wahern »

teddyh wrote: post #21

Encryption usually solves three problems: 1. Authenticity of data; i.e. fixing DNS spoofing. 2. Privacy 3. Censorship Problem 1 is fixed today by DNSSEC. The best solution for problem 1, 2 and 3 would be if IPsec had a working and deployed PKI, so IPsec could be used for all IP-based traffic, and nobody had to worry about encryption on any layer above that. Lacking that, the next best thing for problem 2 would be for…

DoC doesn't actually address 2 or 3.

I trust Sonic to not data mine or game my DNS queries much more than I trust Google or Cloudflare. I actually run my own recursive resolver locally, but if Firefox or Chrome default to DoC then the effect will be to lessen the privacy of Sonic Internet users, and users of similarly trustworthy ISPs. Worse, the techniques employed by browsers to select between a DoC resolver and a local resolver will inevitably on occasion break anonymizing VPN setups. When the browser becomes the OS, you lose interoperability with third-party software as browsers aren't built as platforms for local interfacing.

And centralization makes censorship easier. A U.S. court may not be able to block resolution of a domain under co.uk, but it definitely can force Google or Cloudflare to block it. And it's much easier to execute an injunction against a small handful of service providers that reach 90% of users than trying to execute one to hundreds or thousands of smaller providers. Here's a recent injunction ordering Cloudflare to block a DNS name: https://torrentfreak.com/us-court-lists-dns-and-routing-serv...

Re: The Big DNS Privacy Debate at FOSDEM

#27

Post by zzzcpan »

wahern wrote: post #26
teddyh wrote: post #21

Encryption usually solves three problems: 1. Authenticity of data; i.e. fixing DNS spoofing. 2. Privacy 3. Censorship Problem 1 is fixed today by DNSSEC. The best solution for problem 1, 2 and 3 would be if IPsec had a working and deployed PKI, so IPsec could be used for all IP-based traffic, and nobody had to worry about encryption on any layer above that. Lacking that, the next best thing for problem 2 would be for…

DoC doesn't actually address 2 or 3. I trust Sonic to not data mine or game my DNS queries much more than I trust Google or Cloudflare. I actually run my own recursive resolver locally, but if Firefox or Chrome default to DoC then the effect will be to lessen the privacy of Sonic Internet users, and users of similarly trustworthy ISPs. Worse, the techniques employed by browsers to select between a DoC resolver and a…

Yeah, centralization against censorship is oxymoron.

Re: The Big DNS Privacy Debate at FOSDEM

#28

Post by icebraining »

vetinari wrote: post #13
Tepix wrote: post #5

Earlier quoted context omitted.

One nice aspect of DoH is that you can use it to circumvent local, lame DNS censorship. But ideally you will use a DoH server that is not run by for-profit companies known for data mongering.

Local censorship is still in your jurisdiction; if you have a grievance with it, you can address that (unless it is blocked for a generally accepted reason). With DNS in cloud, you don't have that option. If the cloud companies do not respond to you, what are you going to do? The Google lack-of-support is well known for how it operates.

If the cloud companies do not respond to you, what are you going to do?

Use another, without having to cancel my whole Internet service, just by changing a configuration.

That said, I think the ISP should probably be the default.

Re: The Big DNS Privacy Debate at FOSDEM

#29

Post by teddyh »

wahern wrote: post #26
teddyh wrote: post #21

Encryption usually solves three problems: 1. Authenticity of data; i.e. fixing DNS spoofing. 2. Privacy 3. Censorship Problem 1 is fixed today by DNSSEC. The best solution for problem 1, 2 and 3 would be if IPsec had a working and deployed PKI, so IPsec could be used for all IP-based traffic, and nobody had to worry about encryption on any layer above that. Lacking that, the next best thing for problem 2 would be for…

DoC doesn't actually address 2 or 3. I trust Sonic to not data mine or game my DNS queries much more than I trust Google or Cloudflare. I actually run my own recursive resolver locally, but if Firefox or Chrome default to DoC then the effect will be to lessen the privacy of Sonic Internet users, and users of similarly trustworthy ISPs. Worse, the techniques employed by browsers to select between a DoC resolver and a…

> DoC

Surely you mean DoH?

> I actually run my own recursive resolver locally

As do I.

> I trust Sonic to not data mine or game my DNS queries much more than I trust Google or Cloudflare. […] And centralization makes censorship easier.

Oh, I agree. When you can't trust the single point of failure to not actually fail or not to be already fundamentally failed, then everything about centralization is bad.

Re: The Big DNS Privacy Debate at FOSDEM

#30

Post by michaelt »

detaro wrote: post #16
rnhmjoj wrote: post #12

DNSCrypt has been around for a decade and works really well. Did everyone forget about it? It's objectively better than running DNS queries over HTTPS: still UDP based, no need to trust a CA but only the DNS server public key, can be cached locally or network-wise, perfect forward secrecy. There are clients[1] for Windows, Android, BSD, Linux, macOS and lots of providers[2]. It's really a shame it hasn't been made in…

Some would argue "still UDP based" is objectively worse, since it can be blocked. I don't think DNSCrypt is better for caching, doesn't it just protect one "leg" from a client (which can be a local cache) to a resolver (which also can be a cache) just like DoH? Similarly for pinning keys (although I think DNSCrypt made exchanging keys easier).

In the internet of the future, DNS will move from UDP to TCP because it's better, and HTTP/3 will move from TCP to UDP because it's better.

Web 4.0 will consolidate these improvements, producing DNS over HTTP over QUIC over UDP.

Post reply on HN