Live data from Hacker News

Improving DNS Privacy with Oblivious DoH

blog.cloudflare.com

161–170 of 367 posts

Re: Improving DNS Privacy with Oblivious DoH

#161

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…

When enterprises own the devices on their networks they can add whatever root certificate they like and MITM filter whatever they like. This makes over the network traffic more secure and does nothing to really impact threat detection.

If you don’t own the device then 1) should you be interfering or snooping the traffic at all? 2) if you need to limit threat then subnet clients you don’t own.

Re: Improving DNS Privacy with Oblivious DoH

#162

Misleading title. Apple devices are not anywhere near ready to utilize this dns protocol. Apart from that, yeah let's shift our dns trust to one of the biggest data resolvers! The irony... Encrypted dns might be already in use by government or military agencies, but they know too well the effects of cascading this tech down to the masses. They will never let this reach the public.

Apple devices are not anywhere near ready to utilize this dns protocol.

The latest versions of macOS and iOS already support DoH and DoT; Apple could push an update tomorrow to enable ODoH tomorrow if they wanted to.

Encrypted dns might be already in use by government or military agencies, but they know too well the effects of cascading this tech down to the masses. They will never let this reach the public.

You do know we've had encrypted DNS for years, right? It has some issues, which this new protocol is designed to address. There's no reason to believe "they" can or will intervene to stop ODoH.

Re: Improving DNS Privacy with Oblivious DoH

#163

Preventing the target resolver from seeing client's IP address breaks GeoDNS. This is already a problem with 1.1.1.1 which doesn't honour the EDNS client subnet extension. Given generally DNS is just the start of an intereaction, usually followed by the connection directly between the client and intended destination, I don't see what kind of snooping these privacy measures are there to prevent.

GeoDNS was always a "works most of the time" hack relying on some widespread (but not universal) implementation details in routing and DNS infrastructure, no?

Re: Improving DNS Privacy with Oblivious DoH

#164
Do I understand this correctly that if DoH is implemented, none of the firewalls will be able to block the web sites? Including the pi-hole firewalls, as an example. If that's the case, this situation can't stand for long. Does this meant that the DoH would need to be extended to allow firewalls to decrypt it?

If not, here is a PaloAlto Networks blog advertising capability to block all DoH traffic, presumably at work [0]. It looks like you might not be able to use DoH at work, the way it currently stands. I wonder what would be the right solution?

[0] https://live.paloaltonetworks.com/t5/blogs/protecting-organi...

Re: Improving DNS Privacy with Oblivious DoH

#165

Do I understand this correctly that if DoH is implemented, none of the firewalls will be able to block the web sites? Including the pi-hole firewalls, as an example. If that's the case, this situation can't stand for long. Does this meant that the DoH would need to be extended to allow firewalls to decrypt it? If not, here is a PaloAlto Networks blog advertising capability to block all DoH traffic, presumably at work…

What's stopping your PiHole from just getting its own HTTPS cert?

Re: Improving DNS Privacy with Oblivious DoH

#167
post #151

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…

The problem is that the things you most want to block can trivially bypass your local DNS filtering - DoH is just standardizing something which has been done for decades. The only effective measure is to block outbound network access and require use of a proxy, possibly optimized by allowing direct traffic only from clients with functioning endpoint monitoring agents.

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.

Re: Improving DNS Privacy with Oblivious DoH

#168
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.

Firefox and Chrome do yes, but none of these standards specify any kind of fall-back behaviour. There are no guarantees that any specific device or application needs to do that or how. There is a cost to firewall rules like that as well. Who is going to maintain a list of all the IPs on the internet that are hosting DoH servers that could be used? What about the potentially more prolific proxies specified in this pro…

You can snoop SNI and use that to block traffic, right? In another thread, someone suggested also stripping the keys for encrypted SNI from DNS queries which, when combined with a firewall that attempts to make a DoH query to every new SNI name it sees might potentially work.

Re: Improving DNS Privacy with Oblivious DoH

#169

Earlier quoted context omitted.

You're definitely right that it is an issue that the traffic is plaintext but there are trade off costs that are not addressed by these standards, mostly in user control and fall back behaviour. You've started using a pi-hole, and presumably are getting value from it. These protocols can potentially make it so you can't use that pi-hole at all. Traffic that is local to a network being unencrypted is not a huge privac…

Can you explain (or share a link) to some proposal for how to enable my pihole to securely talk to upstream resolvers but force all embedded devices on my network to go through the pihole? Anything that lets my pihole sidestep my ISP seems like it'd also work for my xbox.

I don't have any resources handily available for that. I would be truly surprised if pi-hole's don't support DoH though so I'd just try searching for something like "enabling DoH on a pihole" or similar.

Basically sounds like you've already done the hardest parts. Your router is redirecting all DNS traffic to your pi-hole, this will prevent any normal unencrypted DNS traffic from leaving your local network. You pi-hole will be in turn making all the DNS requests. If you turn on DoH for the pi-hole all the DNS requests on your network will be encrypted.

Re: Improving DNS Privacy with Oblivious DoH

#170

Until we get rid of SNI[1] in HTTPS for good there will still be providers (like my ISP) that do deep packet inspection on SNI and kill the connection right away if you happen to visit a forbidden site (and this was western Europe, yesterday, on a site behind CloudFlare) [1] https://en.m.wikipedia.org/wiki/Server_Name_Indication

The correct answer will be reverse, get rid of SNI completely and enforce ESNI everywhere.

Most bad entity now only need to block ESNI, and then the client will happily fallback to plain SNI.

If everyone enforce ESNI only, then it is not gonna going to work.

Just like nowadays, a browser can't view https site is completely useless because most of sites on internet were already encrypted(and the percentage is only going to be more) no matter how useful/useless the site is.

Post reply on HN