Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

DNS-over-HTTPS Policy Requirements for Resolvers

blog.mozilla.org

Post reply on HN
Print view View original

101–110 of 301 posts

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#101

Post by MayeulC »

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.

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.

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#102

Post by selenamarie »

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

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#103

Post by coldacid »

tlrobinson wrote: post #85
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.

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.

Honestly, all these apps shouldn't even bother detecting for DoH or not. If people want to use DoH they can set up their own local resolver and configure their network for it (and for folks on Windows, that could even be packaged third-party).

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#104

Post by KitDuncan »

Nas808 wrote: post #66
stirfrykitty wrote: post #32

Earlier quoted context omitted.

Why not run a Pi-hole? You only stand to benefit. Whilst it doesn't address DoH, it does go a long way in preventing the tracking you mention. It also saves on bandwidth. And because it works at the DNS level, you benefit from the calls not even being made. The Pi-hole can be customized with an endless set of rules to block about any ads, beacons, trackers. Couple this with uBlock Origin, Privacy Badger, Decentraleys…

You can do both, I have a Pi-Hole running alongside the “Cloudflared” package so Dnsmasq forwards lookups to Cloudflare over DoH.

My setup is similar. Pihole with dnssec and dnscrypt-proxy connected to cloudflare. Didn't see a reason to use the cloudflared package instead of dnscrypt-proxy.

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#105

Post by teddyh »

afiori wrote: post #11
localhostdotdev wrote: post #6

pretty cool, I wished chrome did that. firefox is probably going to choose cloudflare (1.1.1.1). I wonder how this plays out with local DNS (e.g. my ISP has some custom domains for me to use, and internal company network addresses)

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

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

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#106

Post by zAy0LfpBZLC8mAC »

captncraig wrote: post #47
dooglius wrote: post #37

Earlier quoted context omitted.

Poor choice of term maybe... you want to get information about communication between endpoints without their consent.

Well its a school. They (or their legal guardians) consent as a condition of using the network.

... where using the network is required for participating in school? That would be an interesting notion of consent.

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#107

Post by pretty_bubbles »

pwnna wrote: post #52
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…

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…

Having a pihole still doesn't prevent applications from using another resolver - for example dig example.com @8.8.8.8 You'd also need to block all other DNS traffic. And even after that, it's tricky, as applications that are not a browser might be doing this with a hardcoded DoH provider.

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#108

Post by foobarbazetc »

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.

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#109

Post by Avamander »

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 helicopter parenting is becoming more visible and I'm grateful for that. Kids deserve internet privacy just as much as real-life privacy.

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#110

Post by foobarbazetc »

pretty_bubbles wrote: post #107
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…

Having a pihole still doesn't prevent applications from using another resolver - for example dig example.com @8.8.8.8 You'd also need to block all other DNS traffic. And even after that, it's tricky, as applications that are not a browser might be doing this with a hardcoded DoH provider.

There’s a way to redirect any port 53 traffic back to your pihole if you have enough control over the gateway, but I don’t know if it’s worth doing. Breaks a bunch of things you’d normally do to debug whatever.
Post reply on HN