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

Improving DNS Privacy with Oblivious DoH

blog.cloudflare.com

Post reply on HN
Print view View original

191–200 of 367 posts

Re: Improving DNS Privacy with Oblivious DoH

#191

Post by salgernon »

hkt wrote: post #122
TrueDuality wrote: post #119

The biggest and most consistent downside I see with these DNS enhancements is that it prevents filtering at the network level. Querying nameservers is being pushed into applications themselves to support these new features (such as Chrome and Firefox), which bypasses any system resolvers configured on the host. In most cases there is no way to signal from the network that it is not desirable to do this (Firefox being…

Applications still have fallback though, right? If so, I foresee blocks on DoH/etc to common resolvers like 8.8.8.8 and 1.1.1.1. I'll be blocking them at home on the assumption that I only want regular DNS lookups so I can point them to my own DNS server etc.

Trying to do content filtering on the kids chrome books for remote learning, I installed a pi-hole and was generally pleased with it. Then the kids (8 & 12) figured out to change the dns to cloudflare or google directly. I ended up having to add static routes on the router to block those paths.

(I need to block distraction sites during instruction time - otherwise it’s endless Minecraft videos while in zoom meetings...)

Re: Improving DNS Privacy with Oblivious DoH

#194

Post by zamadatix »

admax88q wrote: post #174
TrueDuality wrote: post #119

The biggest and most consistent downside I see with these DNS enhancements is that it prevents filtering at the network level. Querying nameservers is being pushed into applications themselves to support these new features (such as Chrome and Firefox), which bypasses any system resolvers configured on the host. In most cases there is no way to signal from the network that it is not desirable to do this (Firefox being…

Pi-hole is still very much niche, and outside of that and enterprise network admins, the majority of users are stuck using the trash resolver of their operating system directed to the trash DNS servers of their ISP. If DNS level blocking ever becomes popular enough, malware authors will change their systems to not use the system's DNS, or to use hard coded DNS over TLS/HTTP servers that they know will serve them the…

DNS level blocking is extraordinarily common in enterprise settings though so the cat and mouse game for malware trying to avoid it is decades in the making at this point, pi-hole is just a recent common name in the prosumer space.

Re: Improving DNS Privacy with Oblivious DoH

#195

Post by Sophira »

diegocg wrote: post #105
baskire wrote: post #69

Earlier quoted context omitted.

All I see is a proxy service and a way for cloudflare to get access to the data

The proxy sees the client IP, but can't look at the encrypted DNS request. The DNS server sees (deciphers) the DNS query, but not the client IP address. It's a proxy, but with the sensible data encrypted with the server's public keys to hide it from the proxy. Cloudflare never knows who is sending the requests. How can they get access to the data?

While individual clients may not be easily identifiable, there's still a measure of identification that could be made, if you were to configure the public key DNS server to send a different (but persistent) public key to each IP address which asks for the DNS record. (Probably an ISP's caching nameserver.)

You can't tell how many people are going to be covered by that public key, but you could probably make educated guesses, or combine this with other metadata.

Re: Improving DNS Privacy with Oblivious DoH

#196

Post by jlgaddis »

chipb wrote: post #176
fiddlerwoaroof wrote: post #167

Earlier quoted context omitted.

How can they trivially bypass this local filtering? If the router is redirecting all port 53 traffic, there is no way to bypass aside from some alternate name resolution scheme.

How well does the redirect scheme work for a device that connects to a central DNS server listening on, say, port 5353 instead? What about 80 or 443?

https://en.wikipedia.org/wiki/Perfect_is_the_enemy_of_good

Re: Improving DNS Privacy with Oblivious DoH

#197

Post by remarkEon »

salgernon wrote: post #191
hkt wrote: post #122

Earlier quoted context omitted.

Applications still have fallback though, right? If so, I foresee blocks on DoH/etc to common resolvers like 8.8.8.8 and 1.1.1.1. I'll be blocking them at home on the assumption that I only want regular DNS lookups so I can point them to my own DNS server etc.

Trying to do content filtering on the kids chrome books for remote learning, I installed a pi-hole and was generally pleased with it. Then the kids (8 & 12) figured out to change the dns to cloudflare or google directly. I ended up having to add static routes on the router to block those paths. (I need to block distraction sites during instruction time - otherwise it’s endless Minecraft videos while in zoom meetings.…

Any "how to" recommendations for setting up something similar? I have a pi-hole but after reading this thread I feel like im severely under-utilizing it.

Re: Improving DNS Privacy with Oblivious DoH

#198

Post by vanshg »

jlgaddis wrote: post #189

Even better, IMO, would be if all targets were also proxies and a client could choose -- at "query time" -- any combination of (proxy, target) that they prefer. If you wanted to go a step further, you can even allow "chaining" of proxies, such that the path a query takes might be, in an extreme example, similar to how Tor operates: Client -> Proxy 1 -> Proxy 2 -> Proxy 3 -> Target -> Resolver -- Anyways, this is kind…

Sounds like Tor/Onion Routing?

Re: Improving DNS Privacy with Oblivious DoH

#199

Post by theamk »

tptacek wrote: post #93
theamk wrote: post #26

This seems to require DNSSEC as a key function. @tptacek ?

It has nothing to do with DNSSEC.

Huh? They say this:

> The whole process begins with clients that encrypt their query for the target using HPKE. Clients obtain the target’s public key via DNS, where it is bundled into a HTTPS resource record and protected by DNSSEC. When the TTL for this key expires, clients request a new copy of the key as needed (just as they would for an A/AAAA record when that record’s TTL expires). The usage of a target’s DNSSEC-validated public key guarantees that only the intended target can decrypt the query and encrypt a response (answer).

So this looks like relies on DNSSEC as a core part of its security, and that any resolvers willing to participate in this protocol would have to set up one.

Re: Improving DNS Privacy with Oblivious DoH

#200

Post by specto »

hkt wrote: post #122
TrueDuality wrote: post #119

The biggest and most consistent downside I see with these DNS enhancements is that it prevents filtering at the network level. Querying nameservers is being pushed into applications themselves to support these new features (such as Chrome and Firefox), which bypasses any system resolvers configured on the host. In most cases there is no way to signal from the network that it is not desirable to do this (Firefox being…

Applications still have fallback though, right? If so, I foresee blocks on DoH/etc to common resolvers like 8.8.8.8 and 1.1.1.1. I'll be blocking them at home on the assumption that I only want regular DNS lookups so I can point them to my own DNS server etc.

I have blocked 1.1.1.1 and 8.8.8.8 and noticed some devices behave very badly, often crashing or restarting. Debugging the issue, once I removed the firewall rule they behaved normally. Almost all of the affected devices were google related, Android TV for example.
Post reply on HN