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

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#171

Post by xorcist » Wed, Apr 10, 2019, 6:42 PM UTC

protomyth wrote: post #116

MayeulC wrote: post #101

Earlier quoted context omitted.

That's not entierely true. If the domain doesn't resolve via DoH, Firefox will fallback to the system DNS server. network.trr.mode Needs to be set to 2 (fallback), 1 (pick faster), or 0 (dissable DoH) for this to happen. 3 disables the system resolver.

So, the internal domain names leak to Mozilla unless I disable this totally?

To be fair, can anyone really expect otherwise?

If you insist on using a third party resolver for name resolution they will have knowledge of your queries no matter what the protocol. Doing it over tcp and http is not any better, or worse, than doing it over udp. This is something you have to opt in to.

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#172

Post by simondedalus » Wed, Apr 10, 2019, 6:43 PM UTC

isostatic wrote: post #115

simondedalus wrote: post #91

Earlier quoted context omitted.

no, using the nuclear option of removing the browser outright when others work is the smart, efficient option that someone who actually works in IT with limited resources would (and should) use. this stuff about finding all the right config files during "basic hardening" and having it just work is the stuff of armchair commenters and people who do IT/security on a well funded, sufficiently redundant team. assuming th…

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 config changes they push (however they would push them) took, worked, etc. so they block the app. maybe eventually they reinstall it. welcome to IT.

...which reinforces my point about how people actually doing this and people speculating about it tend to respond to issues like this.

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#173

Post by protomyth » Wed, Apr 10, 2019, 6:44 PM UTC

xorcist wrote: post #171

protomyth wrote: post #116

Earlier quoted context omitted.

So, the internal domain names leak to Mozilla unless I disable this totally?

To be fair, can anyone really expect otherwise? If you insist on using a third party resolver for name resolution they will have knowledge of your queries no matter what the protocol. Doing it over tcp and http is not any better, or worse, than doing it over udp. This is something you have to opt in to.

> This is something you have to opt in to.

Does it come turned off by default?

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#174

Post by tialaramex » Wed, Apr 10, 2019, 6:44 PM UTC

josteink wrote: post #143

tlrobinson wrote: post #85

Earlier quoted context omitted.

How far off are we from DoH being supported by common operating systems, DHCP, etc? It would be nice if these apps could detect whether the system is using DoH and only fall back to their own DoH resolver in the case they're using "legacy" DNS.

> How far off are we from DoH being supported by common operating systems, DHCP, etc? To my knowledge none. Nobody is doing this, because it subverts how DNS is supposed to operate. > It would be nice if these apps could detect whether the system is using DoH and only fall back to their own DoH resolver in the case they're using "legacy" DNS. Yeah. Good luck diagnosing that when something stops working as expected.

> To my knowledge none. Nobody is doing this, because it subverts how DNS is supposed to operate.

Huh? Of course people do this, it's a standard way to do DNS that improves over older DNS wire protocols by offering better security properties. It's unfortunate that we had to involve HTTP in this, but needs must.

For example you can drop in an NSS replacement that uses DoH instead of conventional DNS for all your glibc software, or you can get software from a variety of sources that runs on UDP port 53 of your local machine like a normal DNS relay but uses DoH to someone trustworthy to deliver.

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#175

Post by xorcist » Wed, Apr 10, 2019, 6:50 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…

This is perhaps a stupid question without context, but doesn't every kid of the age where this kind of things is an issue carry their own smartphone nowadays? With mobile Internet?

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#176

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

I'm mostly like you, except I've seen where DoH (or rather the equivalent DNS control) can go wrong on my local network. I have a NAS, and did not set up the manufacturer's optional global DNS routing (because why the heck should anything on the internet know anything about my NAS). Unfortunately that means my Chromecast doesn't stream files off it properly, because that hard codes to using Google's global DNS servers (8.8.8.8), which isn't going to know about my local hostnames (nas.lan). I've had to change things to use IP addresses instead.

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#177

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

shawnz wrote: post #163

EvanAnderson wrote: post #156

Earlier quoted context omitted.

Macro-level view: The Mozilla Foundation may think that DNS-over-HTTPS is about "safety", but they're unwittingly furthering the agenda of those who would profit from the Internet not being decentralized. A decentralized Internet filled with devices that end users can control, should they choose, is a good thing for society, I'd argue. DNS-over-HTTPS is another piece of technology that can be used to eliminate that.…

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.

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#178

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

> 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? Same thing. Any reverse DNS set up? What protocols and public services do you run? Do any expose hostnames in the protocol handshake? Then you are in the public Internet scan datasets.

As soon as you run any kind of SSL on any of your protocols your hostname is in the SNI header.

Host names are visible in a number of ways. It is best to consider them public data. I have seen a number of ISPs from the inside, and none of them has had any interesting in wiretapping their customer's DNS data. I'm not saying it doesn't happen, but it can't be very common. They have much more interesting data available to them should they want to go down that road.

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#179

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

the8472 wrote: post #147

bluejekyll wrote: post #141

Earlier quoted context omitted.

Maybe I'm misunderstanding something, but aren't you talking about running a stub/recursive resolver with DNSCurve? You could do the same with DoT, or DoH. It sounds like DNSCurve might be easier to configure and setup from your perspective?

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.

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#180

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

simondedalus wrote: post #91

close04 wrote: post #79

Earlier quoted context omitted.

Saving time by applying a non-solution 9like removing one browser instead of treating the root cause) is not actually saving anything. You just kick the problem further down the road. Firefox prefs are documented even if not in the most user friendly way [0][1][2][3]. For the most part performing some basic hardening and other useful config on the browser takes less than a day. A person with some IT background should…

no, using the nuclear option of removing the browser outright when others work is the smart, efficient option that someone who actually works in IT with limited resources would (and should) use. this stuff about finding all the right config files during "basic hardening" and having it just work is the stuff of armchair commenters and people who do IT/security on a well funded, sufficiently redundant team. assuming th…

So tell me then, what exactly are you achieving with removing Firefox when the same bypass can easily be achieved with Chrome? Remove Chrome also? Call the well funded security team to configure whatever browser you’ll eventually have to use?

The problem with half assed work is that you still put in some effort but reap none of the rewards. You work to uninstall Firefox from dozens of computers but get exactly 0 results because now you’ll have to configure Chrome. Default installations of both browsers are perfect for home use but woefully inadequate for controlled networks.

And in the end you put in just about as much effort as changing some flags in any one of the dozens of example config files available on the internet and copying it on every machine.