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

261–270 of 301 posts

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#261

Post by protomyth »

darkhorn wrote: post #259
protomyth wrote: post #159

What is the justification for an app to resolve domain names differently than the services the operating system provides? I am really curious why this is a thing.

Windows doesn't provide privacy when it comes to DNS queries. It still uses old fashion, plain text DNS. Firefox is trying to protect its users from prying eyes.

Then complain to Microsoft, ship VPN software like Cloud Flare, and quit doing things in the browser that aren't browsing. This attitude that "I can suck functions into the browser" that do not take into account all the scenarios that OS vendors already have to deal with is a pain in the butt.

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#262

Post by kylek »

topranks wrote: post #241
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.

Seems all for not :|

I don't suppose there are any proposals to replace how SNIs are transmitted? (sans-vpn/tor, that is)

Does QUIC/HTTP[23] do anything different?

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#263

Post by protomyth »

moosingin3space wrote: post #169
protomyth wrote: post #165

Earlier quoted context omitted.

So, when the user types in internal.mydomain.com, it gets sent to Cloudflare then they query my public domain server which doesn't have the entry so it falls back to checking the DNS the system has listed. Is Firefox going to cache the IP like the OS does?

The behaviour depends on a few preferences: * network.trr.mode can be set to 0 (disabled), 1 (race native vs TRR), 2 (TRR first, OS DNS as fallback), 3 (TRR only), 4 (run native and TRR in parallel but use native results, save TRR timings for telemetry), or 5 (off by choice) * network.trr.uri configures which DoH endpoint is queried Firefox does maintain a DNS cache, even if you use the native DNS resolver. You can v…

So, I really need to set 5 because 0 will probably later become default consent to use DNS-over-HTTPS.

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#264

Post by zaarn »

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…

It's entirely within the intentions of browser vendors to make blocking of content without consent of a user hard or even impossible.

If the school cannot be bothered to block content properly (ie, only via DNS block) then that is their own fault. The tools exist to block on an IP level.

For all computers the school owns, they SHOULD definitely do HTTPS MitM.

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#265

Post by zaarn »

stupidthrottle wrote: post #145
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.

> 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. In which case these applications are either broken or malware. The application needs to fix that by using DNS supplied by the OS, as everyone should do.

There are plenty of reasons to use a different resolve on app vs OS level, not only for malware or "broken" applications.

The DNS setting by the OS, just like the proxy settings, is a first suggestion on how to connect.

Chrome will contact 8.8.8.8 in certain circumstances and Firefox has DoH. Both can set proxy settings different from system via various means.

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#266

Post by zaarn »

michaelt wrote: post #150
Avamander wrote: post #125

Earlier quoted context omitted.

The original commenter talked about BYOD though, maybe school-given devices are set-up so that they don't let kids do whatever they want. In the case of BYOD, if you're not okay with your kid having an Internet-connected device and that they're going to use it responsibly then don't give him/her one or only allow it under parental supervision. If we're carefully watching and teaching kids kids when they're handling k…

If your child is supervised on the internet and doesn't have a tablet, and mine isn't and does, and my child showed your child stuff you disapproved of while in school, would you complain to the school? Because some parents would.

Then your child could simply download the content at home and show it at school without internet connection.

Parent would still complain.

The solution isn't to play helicopter-parent because other parents might helicopter even more.

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#267

Post by judge2020 »

stupidthrottle wrote: post #146
judge2020 wrote: post #74

Earlier quoted context omitted.

The issue comes from network operators wanting to control DNS from being a middleman in the connection, but there is no way to ensure the people acting as middlemen in the connection are authorized to be in the middle or authorized to change those DNS requests. If a network operator can change DNS, then the ISP, network hops, or a malicious twin AP can as well.

> If a network operator can change DNS The network operator provides an IP through the DHCP response, which also includes proper DNS-settings for that network. How is this malicious or replacing “your” DNS? The DNS belongs to the network.

ISPs also provide "their" DNS rr's. That does not mean you have to use ISPs' DNS RR to access the DNS.

> The DNS belongs to the network.

This is the question - should the network really be able to tell the client what IP corresponds with a DNS name? if no, then there's no good solution to blocking websites where you can't install things on the client's device. Meanwhile, if you say yes, then you must also say yes to ISPs being able to tell the client what IP corresponds to a DNS name. The only solution in an enterprise context is to buy new hardware (or install a software update if Cisco is feeling benevolent) that runs a DoH server. In a school-bocking-porn context, you could ban the biggest offenders via IP (mindgeek sites have a dedicated IP space I think, and you could cron your own DNS lookups for other non-CDN sites) and use SNI whitelist until eSNI is added to iOS.

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#268

Post by AnaniasAnanas »

moosingin3space wrote: post #170
AnaniasAnanas wrote: post #45

Earlier quoted context omitted.

This is certainly a valid argument, though two of the other solutions (plus dns over tls) avoid this issue as well.

How does DoT avoid this issue? IIRC, DoT runs over port 853, which is trivial to block.

I am pretty sure that the client can use a bridge to connect.

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#269

Post by mike-cardwell »

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 really equivalent. Our DNS servers know every single website we visit, and when we visit them.

There's no way we should take that information and centralise it into the hands of a few big providers. No matter how many pinky promises they make to not look at it.

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#270

Post by vetinari »

UnFleshedOne wrote: post #245
vetinari wrote: post #167

Earlier quoted context omitted.

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

The point is not stopping them downloading this stuff.

The point is stopping them downloading this stuff using schools property or infrastructure. If they download it elsewhere, it is someone others problem then. If someone complains, its someone elses' fault, and the school can fingerpoint.

If they just bring it to the school, they can be disciplined, but no other steps need to be taken.

Post reply on HN