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

DNS-over-HTTPS Policy Requirements for Resolvers

blog.mozilla.org

Post reply on HN
Print view View original

191–200 of 301 posts

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#191

Post by tlrobinson »

josteink wrote: post #137
tlrobinson wrote: post #112

Earlier quoted context omitted.

I can think of 3 main use-cases for DNS blocking on a network level: 1. content policies: blocking porn, censorship, etc (already easily circumvented by changing DNS or using a VPN) 2. preventing malware command and control: blocking domains that malware phones home to (already easily circumvented by including their own resolver, etc) 3. preventing malware infection: blocking domains serving malware (you might lump "…

> It seems like it would be best if operating systems implemented DoH at the system level, including DHCP support, so devices could use the network's DoH resolver which might do malware blocking. They already do that. It’s called DNS.

Of course, but it's not encrypted.

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#192

Post by Spivak »

nykolasz wrote: post #21
majke wrote: post #14

Earlier quoted context omitted.

(full disclosure: I'm affiliated to Cloudflare, but opinions here are my own of course) Thanks for posting this. I knew Paul is against DoH, but never understood his specific arguments. He has great comment about DoT (dns over TLS) couple of minutes before the linked youtube (I agree with him on that). Personally I'm not an "owner" of the networks I'm connecting to. My home router is managed by my ISP, I don't run pi…

I work at a k12 school and I am involved with many IT admins from other schools. Some schools already started to block Firefox from being installed because it was being used as a "VPN" by some elementary students to access porn - at school. Guess what this VPN was? Just DNS over HTTPS. There is a fine line between your ISP and local network operators that NEED to apply some security policies to their traffic. Even Go…

Look I sympathize with all the k12 network operators that have to apply all these brain-dead content filtering policies -- I used to be one. But surely you recognize that someone external to my device that can inspect, modify, compromise the security of, or block my connection to any part of the public internet is the enemy right?

You're free to do whatever you like with devices that you own and you're also free to have an acceptable use policy on your network but breaking security and privacy to accomplish it is the exact wrong way to go about it.

In my ideal world school BYOD devices would either not be allowed at or be given a private single-device VLAN with a direct unfiltered connection upstream, and made clear in policy that the school doesn't own, support, or control any aspect of them. No different whatsoever than students using their cellular connection.

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#193

Post by LinuxBender »

Spivak wrote: post #186
LinuxBender wrote: post #140

Earlier quoted context omitted.

You can use special paint on the buildings that blocks RF. There are also cell phone jammers. They require a license and approval from the FCC and have legal implications / risks.

Blocking RF is illegal if it's done with the intent you describe. It's fine if your building gets terrible or no reception but if you purposely design it that way you're not protected.

There are a number of organizations and businesses that block RF. Their legal team review the local statutes and the employees sign acceptance in the AUP onboarding documentation.

To your point, there are certainly countries and jurisdictions that do not permit blocking RF or have strict exceptions.

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#194

Post by Spivak »

the8472 wrote: post #121
majke wrote: post #14

Earlier quoted context omitted.

(full disclosure: I'm affiliated to Cloudflare, but opinions here are my own of course) Thanks for posting this. I knew Paul is against DoH, but never understood his specific arguments. He has great comment about DoT (dns over TLS) couple of minutes before the linked youtube (I agree with him on that). Personally I'm not an "owner" of the networks I'm connecting to. My home router is managed by my ISP, I don't run pi…

If you don't trust your network why don't you install a DNS stub resolver that tunnels to some external resolver that you trust and then set the OS to use localhost? Don't push things into applications and make things more difficult for everyone else when you can secure your own computer.

> install a DNS stub resolver that tunnels to some external resolver that you trust.

Because the we're dealing with computers as they actually exist and are configured. And within epsilon every personal computer on the planet is configured to trust DHCP and set their DNS servers to whatever is offered. So we're in a situation where these particular applications also don't really trust the OS to a certain extent.

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#195

Post by phicoh »

vetinari wrote: post #187
phicoh wrote: post #67

Earlier quoted context omitted.

I don't like software defaulting to sending all DNS queries to a large cloud provider. That strikes me as bad for privacy. But I don't understand the network argument. If you are perfectly fine with TLS traffic then insisting on seeing DNS traffic sounds weird to me. At the same time, if you force TLS traffic to go through a proxy then that will immediately restore visibility of DNS as well. I guess network operators…

The GP isn't arguing against TLS; he is arguing against random apps ignoring network-wide settings. When such app breaks, he cannot diagnose the problem, he has to diagnose first that the problem is caused by an app that ignores a setting it shouldn't ignore.

It is always the case that an app can break due to something in the app itself. An app may for example link with a different TLS implementation that breaks. Or an app may use the local DNS resolvers but do DNSSEC local validation.

With QUIC (HTTP3) a large part of the network stack will be part of the application. So you lose that visibility as well.

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#196

Post by Spivak »

the8472 wrote: post #123
sroussey wrote: post #29

Earlier quoted context omitted.

SNI is getting encrypted soon too

Only if you go through big, centralized cloud providers fronting the traffic. You're just replacing your ISP with the the CDN.

The person who wrote your application stood it up using that CDN though. There are two parties we're concerned about: you and the entity you're communicating with.

You trust your device and the entity, and the entity trusts the infrastructure and services they're using. Everything else is the enemy. So moving the barrier to a CDN which the entity trusts is actually an improvement over intermediate ISPs which neither of you trust.

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#197

Post by the8472 »

Spivak wrote: post #196
the8472 wrote: post #123

Earlier quoted context omitted.

Only if you go through big, centralized cloud providers fronting the traffic. You're just replacing your ISP with the the CDN.

The person who wrote your application stood it up using that CDN though. There are two parties we're concerned about: you and the entity you're communicating with. You trust your device and the entity, and the entity trusts the infrastructure and services they're using. Everything else is the enemy. So moving the barrier to a CDN which the entity trusts is actually an improvement over intermediate ISPs which neither…

They may simply not care and only "trust" the CDN in so far as it bypasses local resolvers. I.e. they might be using it for reasons not aligned with my interests and not vet the CDN at all.

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#198

Post by Spivak »

vetinari wrote: post #157
wbl wrote: post #153

Earlier quoted context omitted.

So whose device is it anyway? I don't want to use my ISP's lying DNS resolver.

On your router, you can configure whatever you want to use for the DNS. You were able to do that for years. But I want all the devices and apps to use whatever the local network tells them. I don't want to reconfigure the browser every time I connect at home/work/customer place/etc. P.S. My ISP's DNS doesn't lie. Maybe you should vote with your money and choose better.

"Network operators should be able to set DNS servers for client devices."

"You can configure your router, a client device, to use whatever DNS server you want in defiance of your ISP, a network operator."

Which one do you want?

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#199

Post by stirfrykitty »

vetinari wrote: post #177
shawnz wrote: post #163

Earlier quoted context omitted.

Regarding your second point, this change will improve privacy for your clients and make it harder for bad actors to take advantage of your network. So what's not to like? Just because your old tooling won't work anymore doesn't mean that this change is a bad thing for clients.

If it improves privacy for the clients, it also improves privacy for the malware, and you won't be able to monitor or be alerted of it.

Most modern firewalls can decrypt/re-encrypt all traffic on the fly. The end user doesn't even notice. I've done this at my last two jobs.

More here: https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?...

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#200

Post by the8472 »

Spivak wrote: post #194
the8472 wrote: post #121

Earlier quoted context omitted.

If you don't trust your network why don't you install a DNS stub resolver that tunnels to some external resolver that you trust and then set the OS to use localhost? Don't push things into applications and make things more difficult for everyone else when you can secure your own computer.

> install a DNS stub resolver that tunnels to some external resolver that you trust. Because the we're dealing with computers as they actually exist and are configured. And within epsilon every personal computer on the planet is configured to trust DHCP and set their DNS servers to whatever is offered. So we're in a situation where these particular applications also don't really trust the OS to a certain extent.

You have that backwards. It's applications that are less than trustworthy. That's why we try to sandbox them.

As for the DHCP part, if you're on a public network you should only trust it as far as you need it to bootstrap your tunnel over which you can then finally contact a trusted resolver.

OS resolver -> a single thing you need to secure every app uses its own resolver -> complete mess which makes it harder to ensure privacy of your traffic

Post reply on HN