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

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#241

Post by topranks » Wed, Apr 10, 2019, 11:44 PM UTC

kylek wrote: post #168

(It's been a long time since I've actually set up a DNS server and am pretty fuzzy on some details - so I'm going to state this like a real nooby to hopefully get an ELI5 answer) If I were to set up my own DoH server, would its queries to upstream (root??) servers (and subsequent recursed servers) be encrypted? (Simpler: does running a DNS server "on-premise", or even in the cloud, actually protect you from anything?…

No, DoH only deals with client to resolver encryption.

Recursive lookups from the resolver to authoritative DNS servers from the root down are not encrypted.

Really what you are doing is switching between telling your ISP all the domains you look up to telling Google/Cloudflare. Except your ISP can still see SNIs so you’re really just telling Google/Cloudflare in addition to your ISP.

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#242

Post by topranks » Wed, Apr 10, 2019, 11:47 PM UTC

LinuxBender wrote: post #148

Has anyone started contributing lists of all the public DoH resolvers on any of the block-lists? e.g. [1] [2] [1] - https://iplists.firehol.org/ [2] - https://github.com/firehol/blocklist-ipsets

Someone has a list here:

https://github.com/curl/curl/wiki/DNS-over-HTTPS

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#243

Post by phyzome » Wed, Apr 10, 2019, 11:49 PM UTC

xorcist wrote: post #178

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…

> The only way they could be exposed for crawling is by my DNS provider leaking the DNS traffic to some shady third-party. There are a number of other, perhaps more likely, reasons your hostnames have leaked. Have you got any certificates for any of those names? Then they are in the public CT database which numerous people constantly scan for interesting data. Are any of your DNS zones enumerable for some reason? Sam…

One way to test this would be to have the browser pointed to a page on a wildcard subdomain, and have a port 80 non-SSL listener logging requests.

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#244

Post by topranks » Wed, Apr 10, 2019, 11:51 PM UTC

bzbarsky wrote: post #222

slim wrote: post #13

tl;dr Firefox will ignore your DNS settings and use his own (DoH)

Nothing in the article says anything about that. The article talks about Firefox behavior when DoH is enabled. It's not enabled by default. The article doesn't say it's getting enabled by default, or under what conditions it might get enabled by default.

They have already stated they will be switching it on by default:

https://mailarchive.ietf.org/arch/msg/doh/po6GCAJ52BAKuyL-dZ...

“4. The user will be informed that we have enabled use of a TRR and have the opportunity to turn it off at that time, but will not be required to opt-in to get DoH with a TRR.”

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#245

Post by UnFleshedOne » Wed, Apr 10, 2019, 11:52 PM UTC

vetinari wrote: post #167

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…

> the students can still get access to whatever at home, or using coffeeshop WiFi, or whatever. That's fine, these are not school responsibility. Once the parents complain, you can redirect them to their home or coffeeshop.

What stops them from downloading this stuff and still bringing it to school?

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#246

Post by simondedalus » Wed, Apr 10, 2019, 11:53 PM UTC

close04 wrote: post #218

simondedalus wrote: post #212

Earlier quoted context omitted.

the DNS filtering works on chrome. yes, people can bypass it, but it doesn't even work on firefox, so they remove firefox. this isn't rocket science, and you're being foolishly contrarian instead of trying to understand what the original commenter's actual situation is. this leads me to believe that you are hypothesizing about work you don't do, but feel perfectly qualified to talk about "half assing" things.

> you're being foolishly contrarian instead of trying to understand what the original commenter's actual situation is Perhaps because he's describing 2 different situations. One where "some schools" are removing Firefox, and one where it's not an option for him because of BYOD. Uninstalling Firefox is exactly the solution he can't apply. So I still maintain that the other schools that fully control the clients could…

this is getting really boring and repetitive, but you didn't give a "cheaper" solution, you gave an administratively more expensive solution (change files on machines rather than bulk remove an app which is out of the box functionality for many products IT like this would use), along with moving the goal posts; the goal is "keep my DNS filtering working," not "make sure no one ever gets to the porn site."

of course, you would need to do more in chrome (and windows/osx/ubuntu generally) to stop traffic to a site if a student knows what they're doing. that's not the point. the point is: we have this control in place. we've agreed it's working well enough. people can bypass the control simply by using firefox. to avoid adding overhead, we ditch firefox (for now). it's that simple.

as for future-proofing, that's a luxury. ...and part of why it's a luxury is that some goals ("make all traffic to any porn sites impossible on our school network") just aren't going to be met by budget IT.

re: BYOD, for that i go over to the armchair tech purist side i'm afraid, and just say "well, you allow that, so you need to get over that they can use VPNs and stuff. you're not DOJ or some wealthy corporation with important IP assets and equally 'important' VIP execs that insist on bringing their OSX 10.6 MBP to work. you don't get to have all the cool controls that might allow BYOD. sorry."

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#247

Post by close04 » Thu, Apr 11, 2019, 12:01 AM UTC

packet_nerd wrote: post #88

AndyMcConachie wrote: post #81

Earlier quoted context omitted.

DoH is different because it masquerades as HTTPS traffic. You can block DNS traffic sent to servers configured in custom hosts files, but you can't block DoH unless you either have a list of every DoH server in existance, or block all HTTPS traffic. That's kind of the entire point of DoH. DNS-over-TLS (DoT) provides TLS encryption for DNS traffic, but runs over port 853 so network operators can control where queries…

> You can block DNS traffic sent to servers configured in custom hosts files You're thinking of configuring a custom DNS server, which is not related to the hosts file. The hosts file replaces DNS so there would be no network traffic to block. Theoretically a kid who really wants his porn could manually add the name-to-IP entries for his favorite sites to his local hosts file, completely bypassing any DNS based filte…

If you want to prevent anything like this you either have strong (centralized) controls on the client side - policies hardening the client to the point where no reasonable exploitation avenue is left (no hosts file, no running portable browser, no changing settings, etc.), or strong controls on the network - proxy and make sure no matter what the client wants it goes only where it's allowed (no VPN, no DNS filter bypass, etc.).

Maybe the occasional brilliant kids will find a way, good for them. But there's a limit to how much "ghetto administration" you can do without expending any resources on it and still have your measures hold after a few weeks of curious students probing at them.

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#248

Post by simondedalus » Thu, Apr 11, 2019, 12:13 AM UTC

close04 wrote: post #217

simondedalus wrote: post #211

Earlier quoted context omitted.

of course it's possible to do so. but DNS filtering works for most users, and is much easier to centrally manage on a budget (in terms of time / people / money) than browser settings. i'm belaboring this point now, but people who actually do this stuff know that you can't just throw up a GPO to fiddle with chrome settings and expect everything to work. this culture of "power users" thinking they know the best course…

> know that you can't just throw up a GPO to fiddle with chrome settings I thought we were talking about how hard it is to fix Firefox. This can be done on a budget - part of an afternoon - since it can be very easily managed with a plain old config file copied to all machines (at least until a couple of versions ago). With this gone you're left with Chrome. How would you make sure no user can use any one of the mult…

as i replied in the comment below, the goal isn't "absolute porn free paradise," it's "keep our current control working." sound shortsighted to you? it is. it's also the easiest thing, and frees everyone up to do other, more important work than impressing people who are aghast that an organization would uninstall 1 of 2 browsers b/c it bypasses some control of theirs.

as for once chrome implements DOH, they'd cross that bridge when they came to it. it's an uphill battle, because really content filtering, of course, should not be done through browser settings (remotely managed or otherwise), nor solely through DNS. if whoever tells IT what to do in that school district is hellbent on it being impossible to browse to pornhub, they'll ultimately need a layer 7 firewall. but again, when you're on the budget, you do fastest / cheapest / most effective.

(and if we return to pure hypothetical, i would argue that dns filtering really is the best way in their case, because anyone who could bypass that--besides just using firefox--will be able to bypass better chrome config, or your firefox config change, etc, since they can just edit host file, etc etc etc)

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#249

Post by snazz » Thu, Apr 11, 2019, 12:16 AM UTC

shawnz wrote: post #213

syshum wrote: post #210

Earlier quoted context omitted.

That works by Man in the middle attacks of SSL and Only works on Enterprise Networks for devices owned by the enterprise because the Enterprise Installs their own Root Certs on all devices that "tricks" the browsers into believing they are "google.com" not the real google.com

Right, which is exactly how it should be. If you want to perform a purposeful man in the middle attack on your clients, then you SHOULD be required to install your root cert on their workstations. With unencrypted DNS, it just means that you can perform the same attack with NO specific approval by the client workstation. How is that better?

You get an HTTPS error if someone performs a DNS MITM and you’re not set up specifically to trust their certificate. It’s equivalent to performing an HTTPS MITM without the root cert installed.

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#250

Post by roca » Thu, Apr 11, 2019, 12:30 AM UTC

move-on-by wrote: post #9

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.

Without a doubt, DNS-over-HTTPS introduces some major concerns from a network operator and security perspective. But I'm also very privacy focused, and am conflicted on the issue. >[Mozilla] believe that they need to build technology that will accommodate a hostile network operator who is going to replace your DNS with things pointing to their advertising servers or is going to monitor what you do and send it off to…

The thing is, those devices are going to do that even if Mozilla drops DoH, the RFCs are burned and everyone responsible shot.

So the options are: * Make DoH illegal somehow * Take advantage of it as best we can