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

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#131

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

rmdoss wrote: post #94

Note that with DoH on Firefox, your intranet domains do not work. Had issues with it before and had to disable DoH just to access our company printer. Also causes issues with DC. That goes into the argument that DNS (domain name lookup) should be a system and network-level setting, not an App-based setting.

> Note that with DoH on Firefox, your intranet domains do not work

That’s part of the plan. From now everything is cloud only, and everyone doing anything differently gets thrown under the bus, with less and less control left for the user.

We’re progressing backwards into the future.

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#132

Post by gpm » Wed, Apr 10, 2019, 5:17 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.

Because "normal" = "insecure and not private"? "Legacy" might be a better name for it in the near future.

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#133

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

foobarbazetc wrote: post #108

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…

Think of this more like which CA roots browsers include by default instead of a nefarious plan to stop you from doing whatever you want.

It's not a nefarious plan to stop me from doing what I want in a FOSS browser on a PC where I can compile and run what I want. It will be used that way, however, on locked-down devices users pay for but don't actually own.

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#134

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

laHiesh1 wrote: post #120

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.

Do they bother resolving internal domain names such as example.lan? Otherwise that would be stupid and leaky.

With Windows and AD “internal” names are FQDN, which resolves fine with the DNS server provided with the DHCP settings.

Of course DoH will break this and leak. Enterprises everywhere will hate this and ban Firefox.

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#135

Post by [deleted] » Wed, Apr 10, 2019, 5:19 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…

[deleted]

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#136

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

selenamarie wrote: post #102

rmdoss wrote: post #94

Note that with DoH on Firefox, your intranet domains do not work. Had issues with it before and had to disable DoH just to access our company printer. Also causes issues with DC. That goes into the argument that DNS (domain name lookup) should be a system and network-level setting, not an App-based setting.

I'm working on our DoH implementation. I'm guessing this is a split-horizon set up with a domain that resolves both internally and externally. If you are willing, we're very interested in these situations and coming up with heuristics to detect and disable DoH proactively. We're also looking into standards changes that could make these configurations more reliably detectable at the application level. I'm selena at mo…

As a sysadmin who rails against split-horizon DNS (usually around Active Directory implementations where brain-damaged people have named the AD domain the same as a public Internet domain name) I'm already getting a churning feeling in my stomach thinking about how software is going to mishandle this scenario in DNS-over-HTTPS.

It's going to be particularly god-awful for devices that roam between networks where the "internal" DNS is visible and networks where it isn't. Ugh...

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#137

Post by josteink » Wed, Apr 10, 2019, 5:21 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 "…

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

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#138

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

nykolasz wrote: post #70

pwnna wrote: post #52

Earlier quoted context omitted.

To add to this issue from a personal level: for those who use a Pihole or operate other internal services from within their own home network will now have to change the settings for _every application_ using DoH on that network. This could become a major hassle if the number of devices and owners become large. There's not even a work around for this because I do not directly manage family members' devices (nor would…

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.

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#139

Post by EvanAnderson » Wed, Apr 10, 2019, 5:25 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 "…

Using and embedded resolver or switching to a third-party DNS server, at least within many corporate networks, isn't viable because outbound DNS traffic is allowed only from the "blessed" stub resolvers. That doesn't change scenario 1, however scenarios 2 and 3 are rendered moot.

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#140

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

CydeWeys wrote: post #82

Tushon wrote: post #65

Earlier quoted context omitted.

The OP talked about BYOB, which rarely includes "root access" (either via a root cert for decrypting traffic or admin level access to the machine)..

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.