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

111–120 of 301 posts

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#111

Post by Avamander »

shittyadmin wrote: post #89
ronsor wrote: post #78

Earlier quoted context omitted.

I would not install a school managed backdoor on my device.

So your options are then: - Cry about it and hope they change the policy (they won't) - Accept using your cell data at school instead of their wifi (works, but is expensive) - Bypass it using a VM (requires moderate technical knowledge, networking skills and possibly the ability to bypass vm detection) - Reverse engineer it and crack it to behave the way you want (requires some pretty advanced technical skills) As su…

Kids are clever, if one of their classmates is known to be tech-literate and (s)he's saying the school is snooping on you the amount of shadow IT will rise. Vast majority will install, but also have some other device to bypass.

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#112

Post by tlrobinson »

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 "ads" in this category too, e.x. Pi-hole)

IMHO the 3rd is the only use-case worth trying to solve with DNS blocking, because the user isn't actively trying to circumvent it.

Applications using their own resolvers do make that difficult to do. 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.

Applications like Firefox could fall back to their own DoH resolver if they had a way to detect the system was not using DoH. This would also encourage network operators to support DoH.

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#113

Post by Avamander »

kodablah wrote: post #83
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…

Curious, how does your school solve this with students' phones? Have y'all considered requiring mandatory monitoring apps? Or cell phone data jammers and requiring them use y'all's wifi and require a CA cert install?

Reading these comments I'm more and more disgusted really, how is it okay (to even suggest) that personal devices of kids are so invasively monitored?

They deserve their internet privacy just as much as grown ups do even more so actually given their higher trust in others, if schools are scared of internet's dangers then schools should educate, not wrap kids into digital bubble wrap that will disappear when they leave school leaving them tech-illiterate and vulnerable.

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#114

Post by icebraining »

rndgermandude wrote: post #43
nykolasz wrote: post #35

Earlier quoted context omitted.

Band-aid solution that worked pretty well. Very cheap to implement, widely supported and used by many schools. Our student's data was still private (no emails or passwords being decrypted) and we did the filtering only based on the domain name. It also didn't require an expensive appliance that would be need if did the filtering based on SNI.

A student who really wants to see "the bad" on the internet isn't scared off by blocking some DNS/VPN/proxy traffic. This is wishful thinking. The easiest work-around for students who want to show their mates some "cool porn" is to just save it at home. Or connect to the free wifi of in reach.

But then it's not the school's fault.

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#115

Post by isostatic »

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…

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

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#116

Post by protomyth »

MayeulC wrote: post #101
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.

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

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#117

Post by the8472 »

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 want privacy and consider DNS an operational issue. I run my own stub and recursive resolvers in my networks to avoid relying on centralized entities on the system level and don't want random applications to bypass it and funnel even more information to google or cloudflare than they already get anyway. Today it's firefox, tomorrow it's shady phone apps that want to bypass content filters and ping their trackers.

DoH gains me nothing since I already tunnel the traffic to my resolver. What I really want is something like dnscurve.

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#118

Post by cpeterso »

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?

Not to Mozilla, but to whichever DoH service Firefox is configured to use, by default or by the user. Mozilla isn't running a DoH service.

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#119

Post by the8472 »

foobarbazetc wrote: post #110
pretty_bubbles wrote: post #107

Earlier quoted context omitted.

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.

instead of redirecting you can log it so you can identify suspicious apps

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#120

Post by laHiesh1 »

MayeulC wrote: post #101
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.

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