DNS-over-HTTPS Policy Requirements for Resolvers • Hacker News Board

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#121

Post by the8472 » Wed, Apr 10, 2019, 4:55 PM UTC

majke wrote: post #14

EvanAnderson wrote: post #2

I hadn't been paying much attention to DNS-over-HTTPS, but I recently listened to a talk that Dr. Paul Vixie (of BIND fame) gave that where DNS-over-HTTPS was discussed: https://youtu.be/OxFFTxJv1L4?t=2799 After hearing Dr. Vixie discuss DNS-over-HTTPS from a network operator perspective I'm a lot more wary of the protocol.

(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.

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#122

Post by asark » Wed, Apr 10, 2019, 4:56 PM UTC

Avamander wrote: post #109

nykolasz wrote: post #27

I replied sub-thread, but adding here to give some more visibility to some of the issues DoH is causing and will cause: I work at a k12 school and I am involved on many k12 IT communities. Some schools already removed Firefox from the students computers 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 betwee…

Don't worry. Soon Chrome will also implement DoH and ESNI, then you actually have to either forbid BYOD or actually start teaching students manners, how browsing porn is not okay in school context. I'm really quite annoyed by the connotation that kids should rather be helicopter-parented (by tech or by people) than actually taught what's okay and what's not. The very least the new tech provides is that any silent hel…

I definitely don't want my six year old to be able to use their school-provided, Internet-connected iPad any way they please, with plenty of privacy.

And yeah the actual solution is "don't fucking give a six year old an Internet-connected device of any sort, obviously, you idiots" but they do, so monitoring and blocking are absolutely necessary.

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#123

Post by the8472 » Wed, Apr 10, 2019, 4:57 PM UTC

sroussey wrote: post #29

zzzcpan wrote: post #19

Earlier quoted context omitted.

Your ISP doesn't really need DNS traffic to know things about you, IP addresses alone leak a lot of information, add to that SNI, response sizes, active probing, clear text traffic, etc. and you should realize that the only thing DoH does is letting one extra party to know what you are doing in addition to your ISP. DoH is net negative for privacy. You need at least a VPN to get to net positive, so that your ISP can'…

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.

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#124

Post by bluejekyll » Wed, Apr 10, 2019, 4:59 PM UTC

the8472 wrote: post #117

bluejekyll wrote: post #92

I’ve begun to think that differences of opinion on the benefits and/or negatives of DoH come from two different perspectives on what DNS is for. What I perceive from the debate is generally that people who dislike DoH tend to perceive it as a network plane protocol, one that is designed for network operations and nothing more (layer 3/4 if you will). Whereas people who tend to want privacy and the other features of D…

I want privacy and consider DNS an operational issue. I run my own stub and recursive resolvers in my networks to avoid relying on centralized entities on the system level and don't want random applications to bypass it and funnel even more information to google or cloudflare than they already get anyway. Today it's firefox, tomorrow it's shady phone apps that want to bypass content filters and ping their trackers. D…

What advantages do you see DNSCurve as having over DoT or DoH? (or DNS-over-Quic as that starts rolling out)

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#125

Post by Avamander » Wed, Apr 10, 2019, 4:59 PM UTC

asark wrote: post #122

Avamander wrote: post #109

Earlier quoted context omitted.

Don't worry. Soon Chrome will also implement DoH and ESNI, then you actually have to either forbid BYOD or actually start teaching students manners, how browsing porn is not okay in school context. I'm really quite annoyed by the connotation that kids should rather be helicopter-parented (by tech or by people) than actually taught what's okay and what's not. The very least the new tech provides is that any silent hel…

I definitely don't want my six year old to be able to use their school-provided, Internet-connected iPad any way they please, with plenty of privacy. And yeah the actual solution is "don't fucking give a six year old an Internet-connected device of any sort, obviously, you idiots" but they do, so monitoring and blocking are absolutely necessary.

The original commenter talked about BYOD though, maybe school-given devices are set-up so that they don't let kids do whatever they want.

In the case of BYOD, if you're not okay with your kid having an Internet-connected device and that they're going to use it responsibly then don't give him/her one or only allow it under parental supervision. If we're carefully watching and teaching kids kids when they're handling knives or matches, why not do so with internet connected devices?

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#126

Post by bluejekyll » Wed, Apr 10, 2019, 5:03 PM UTC

tlrobinson wrote: post #112

bluejekyll wrote: post #92

I’ve begun to think that differences of opinion on the benefits and/or negatives of DoH come from two different perspectives on what DNS is for. What I perceive from the debate is generally that people who dislike DoH tend to perceive it as a network plane protocol, one that is designed for network operations and nothing more (layer 3/4 if you will). Whereas people who tend to want privacy and the other features of D…

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 "…

3 is reasonable. I think you stated that well, "the user isn't actively trying to circumvent it", though I might expand that to include the application isn't actively trying to circumvent it. For passive mitigation of standard browsing as a means of helping protect yourself, yes, but even there, it won't take long for systems to figure out a way to circumvent that.

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#127

Post by danarmak » Wed, Apr 10, 2019, 5:06 PM UTC

gruez wrote: post #60

danarmak wrote: post #31

Earlier quoted context omitted.

> Unfortunately, on our school network, we also allow BYOD (students with their own laptops and ipads), so we will have to have some strict rules to block DoH, the same way we block proxies and vpns. How can you block DoH without doing MITM on all outgoing HTTPS? For that matter, how can you block HTTPS based VPNs like OpenVPN? ETA: I understand you can block IP addresses of DNS resolvers that support DoH. I assumed…

>How can you block DoH without doing MITM on all outgoing HTTPS? For that matter, how can you block HTTPS based VPNs like OpenVPN? OpenVPN isn't HTTPS based. It has TLS support, but AFAIK it's implemented as TLS-over-OpenVPN rather than OpenVPN-over-TLS, so it's still very distiquishable from a HTTPS connection. There are workarounds like using TCP mode over stunnel, though.

You're right! I wasn't aware of that.

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#128

Post by DDub » Wed, Apr 10, 2019, 5:08 PM UTC

tremon wrote: post #97

DDub wrote: post #53

Earlier quoted context omitted.

Sysadmins should concentrate on managing and securing the devices and not the network. This is advantageous with todays mobile workforce where users expect the same experience at the office, coffee shop or home.

Great deflection, but what should network operators do then? And specifically, network security specialists?

Security isn't just about intrusion prevention, it is also about ensuring that the resource is available to the people who need it when they need it.

So, carry on with keeping bad actors off the network and ensuring that there is sufficient capacity and resilience in the network.

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#129

Post by the8472 » Wed, Apr 10, 2019, 5:10 PM UTC

bluejekyll wrote: post #124

the8472 wrote: post #117

Earlier quoted context omitted.

I want privacy and consider DNS an operational issue. I run my own stub and recursive resolvers in my networks to avoid relying on centralized entities on the system level and don't want random applications to bypass it and funnel even more information to google or cloudflare than they already get anyway. Today it's firefox, tomorrow it's shady phone apps that want to bypass content filters and ping their trackers. D…

What advantages do you see DNSCurve as having over DoT or DoH? (or DNS-over-Quic as that starts rolling out)

Securely contacting the authoritative servers from a recursive resolver under my control instead of relying on some big corporation.

Currently DoH or DoT are only used and designed with the goal[0] to secure stub resolver recursive resolver traffic. Someone has to operate that recursive resolver and you have to trust them. So you only shift the problem from having to trust your ISP to having to trust cloudflare/google/etc.

Dnscurve is intended to secure the recursive resolver authoritative traffic, which means you don't have to rely on another party to secure your traffic. I guess dns over dtls could in principle fill the same role, albeit with more overhead.

[0] https://tools.ietf.org/html/rfc8484#section-1

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#130

Post by afiori » Wed, Apr 10, 2019, 5:14 PM UTC

teddyh wrote: post #105

afiori wrote: post #11

Earlier quoted context omitted.

You can set firefox to use the normal DNS as a fallback

One could reasonably wonder why “normal” should be a fallback.

I have two reason to like DoH: public wifi blocking sites and ISPs blocking sites. I understand that it is "wrong" from the perspective of a network stack, but for my use case that is far from being even a weak issue.