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

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#181

Post by close04 » Wed, Apr 10, 2019, 7:07 PM UTC

simondedalus wrote: post #172

isostatic wrote: post #115

Earlier quoted context omitted.

Yes, we should stick with IE6 on all machines, no need for any other browsers

firefox messes up their DNS filtering, chrome doesn't. so they remove firefox and enforce chrome. if you see that as a slippery slope, you're imagining it. they probably 1) have a decent app like ninite to remove and install apps, 2) don't have anything but their production environment, 3) don't have a homogenous environment in terms of patching (maybe they do), 4) don't have people to go around and make sure the con…

> firefox messes up their DNS filtering, chrome doesn't

I take it you assume students are not creative enough to get the exact same result with Chrome? Because it is perfectly possible to do it. Unless of course you take steps to prevent that in Chrome. One way or another you either put in the work or the users will end up doing whatever they please. After configuring the OS doing the same for the browser is a relatively small step.

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#182

Post by [deleted] » Wed, Apr 10, 2019, 7:08 PM UTC

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.

[deleted]

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#183

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

bluejekyll wrote: post #179

the8472 wrote: post #147

Earlier quoted context omitted.

No, the traffic from individual machines to my recursive resolver is already secured or trusted, either because it's a trusted network or going through a tunnel. What I am missing is a way to secure the traffic from the recursive resolver to all the authoritative name servers in the world, i.e. to achieve end-to-end encryption for lookups. Yes I am aware that this would require dnscurve support in most authoritative…

I think we're coming to DNSSEC + TLS vs. DNSCurve at this point. I'm not so convinced that the authenticity of the data you're conferring to the DNSCurve network is conferring greater security than DNSSEC and TLS. I'm not arguing one is better than the other, but I kinda see it as a wash.

DNS-over-(d)TLS approaches don't aim to secure the traffic between recursive resolvers and authoritative servers[0][1]. Is there any newer work going in that direction?

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

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#184

Post by AlexandrB » Wed, Apr 10, 2019, 7:23 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…

> Soon Chrome will also implement DoH and ESNI, then you actually have to either forbid BYOD or actually start teaching students manners...

If you think that this is how it will go, you're very naive. If schools and parents can't block porn anymore, prepare for more legislation that blocks porn by default at the ISP unless you pay some kind of fee - like what the UK has proposed. Also look for a return of "content standards" for sites that want to be kept off the "porn list", like the old broadcast TV content standards.

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#185

Post by tptacek » Wed, Apr 10, 2019, 7:29 PM UTC

bluejekyll wrote: post #179

the8472 wrote: post #147

Earlier quoted context omitted.

No, the traffic from individual machines to my recursive resolver is already secured or trusted, either because it's a trusted network or going through a tunnel. What I am missing is a way to secure the traffic from the recursive resolver to all the authoritative name servers in the world, i.e. to achieve end-to-end encryption for lookups. Yes I am aware that this would require dnscurve support in most authoritative…

I think we're coming to DNSSEC + TLS vs. DNSCurve at this point. I'm not so convinced that the authenticity of the data you're conferring to the DNSCurve network is conferring greater security than DNSSEC and TLS. I'm not arguing one is better than the other, but I kinda see it as a wash.

TLS DNS and DNSCurve perform essentially the same function, so it doesn't make much sense to compare one with DNSSEC and one without. What blurs the line a little is that DNSCurve is explicit about its goal of providing bottom-up DNS security --- in a world with near-universal DNSCurve deployment, the need for DNSSEC would be minimized. But that's in fact true of TLS DNS, as well --- it's just not something the IETF is explicit about.

Both DNSSEC and DNSCurve are basically dead-letter standards at this point; interestingly, the stake through both their hearts is DNS over TLS or HTTPS, but for different reasons: DNSCurve, because DoTLS essentially replaces the entire protocol, and DNSSEC because DoTLS reveals (through its rapid adoption, among other things) how marginal DNSSEC's contribution actually is.

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#186

Post by Spivak » Wed, Apr 10, 2019, 7:30 PM UTC

LinuxBender wrote: post #140

CydeWeys wrote: post #82

Earlier quoted context omitted.

I was referring to the machines they were preventing the installation of Firefox on. For BYOD, I don't know what you're gonna do. Many students have smartphones too (some with tethering), and you can't control what they look at on those either. Plus, even if the school could somehow magically lock everything down 100% within the confines of the school building, the students can still get access to whatever at home, o…

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.

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#187

Post by vetinari » Wed, Apr 10, 2019, 7:35 PM UTC

phicoh wrote: post #67

cremp wrote: post #12

Earlier quoted context omitted.

Because they should! Think a corporate network. If I as a sysadmin set our DHCP options to give out our own resolvers, I expect that every machine on the domain to use ours. DoH breaks that completely; and hence the network operator should have the final say. As a sysadmin myself, if browsers are overriding the basic model of top down, and it hurts me, because when something is wrong, I cant just look on my machine,…

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.

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#188

Post by JohnFen » Wed, Apr 10, 2019, 7:40 PM UTC

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…

I consider DoH too dangerous to allow on my own network, so here's what I did: if you want to use HTTPS from my network, you need to install my root cert. I then proxy all HTTPS traffic to detect and drop DoH exchanges.

I expect that we'll see this sort of thing more and more.

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#189

Post by JohnFen » Wed, Apr 10, 2019, 7:43 PM UTC

josteink wrote: post #138

nykolasz wrote: post #70

Earlier quoted context omitted.

Yep. What happens when Chrome adds DoH support? And Safari? And whatever Gaming app the kids download? Suddenly it will become impossible to manage and maintain. Not even talking about the troubleshooting nightmare. DNS should be a system-level setting, not an App-level setting.

> DNS should be a system-level setting, not an App-level setting. I would go even further: Any app trying to bypass the system-level network settings (like with DoH) should be considered malicious and possibly malware. This is what spam-bots used to do back in the days. Now let’s add Firefox to the list.

> Any app trying to bypass the system-level network settings (like with DoH) should be considered malicious and possibly malware.

This is my point of view precisely.

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#190

Post by throw2016 » Wed, Apr 10, 2019, 7:44 PM UTC

kodablah wrote: post #86

> Our plan is to select a set of Trusted Recursive Resolvers (TRRs) that we will use for DoH resolution in Firefox. Those resolvers will be required to conform to a specific set of policies that put privacy first. So can I manually set one myself to my local pi-hole instance? I have already been setting the TRR about:config values (ala [0]), will that remain? I am wary of Mozilla becoming the arbiter of acceptable DN…

There is a already a crisis of invasive surveillance, profiling and profiting from stalking users. There is also government surveillance that can't be thwarted with its own panopticon of secret orders, secret courts and secret processes.

Both of the above need to be urgently reined in to retain some sense of accountability and democracy. And these efforts including awareness are predominantly coming from outside the technical community.

When the problem is concentrated global monopolies and power how can centralizing more control be the solution? And yet these seem to be the only solutions from the community.