Live data from Hacker News

DNS-over-HTTPS Policy Requirements for Resolvers

blog.mozilla.org

31–40 of 301 posts

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#31

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…

> Unfortunately, on our school network, we also allow BYOD (students with their own laptops and ipads), so we will have to have some strict rules to block DoH, the same way we block proxies and vpns.

How can you block DoH without doing MITM on all outgoing HTTPS? For that matter, how can you block HTTPS based VPNs like OpenVPN?

ETA: I understand you can block IP addresses of DNS resolvers that support DoH. I assumed that to make this work, Mozilla / Google / etc. would serve DoH from the same IPs as some big services, so you wouldn't be able to block DoH without blocking something like Google's homepage.

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#32
post #14

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…

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, Referer Block, and some creative browser settings (about:config) and you are largely safe from prying eyes. JS can be whitelisted, etc. You have nothing to lose.

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#33
post #19

Earlier quoted context omitted.

Your ISP doesn't really need DNS traffic to know things about you, IP addresses alone leak a lot of information, add to that SNI, response sizes, active probing, clear text traffic, etc. and you should realize that the only thing DoH does is letting one extra party to know what you are doing in addition to your ISP. DoH is net negative for privacy. You need at least a VPN to get to net positive, so that your ISP can'…

SNI is getting encrypted soon too

Within next 10 years maybe. It doesn't solve anything though and is plenty of time for DPI vendors to pursue other snooping techniques.

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#35

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…

Ultimately we cannot secure content without being able to look at it (encryption is the problem). We need to be able to look at what the kids are looking at if we want to control what information gets to them. DNS is a band-aid solution with side effects.

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.

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#36

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…

Sounds like it is working perfectly, you want a MITM and this is making that difficult.

Quite the opposite. We don't want MITM and this may force that direction.

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#37

Earlier quoted context omitted.

Sounds like it is working perfectly, you want a MITM and this is making that difficult.

Quite the opposite. We don't want MITM and this may force that direction.

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

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#38
post #10

Still no explanation on why dns-over-https rather than the already widespread dnscrypt or the lesser known dnscurve, dns-over-quic, and dns-over-tor.

DoH has already more adoption than all previous approaches combined. (Note: I don't think DNS-over-QUIC is really any different from DoH. QUIC is just another way of transmitting HTTPS, so you can just do DoH over QUIC.)

> DoH has already more adoption than all previous approaches combined

Are you sure? My experience so far has shown that only dnscrypt is widely supported.

Nevertheless, surely they must had some kind of issue with the existing solutions when they started working on it.

As for DNS over QUIC, I was under the impression that said solution did not make use of HTTP.

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#39

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…

> Unfortunately, on our school network, we also allow BYOD (students with their own laptops and ipads), so we will have to have some strict rules to block DoH, the same way we block proxies and vpns. How can you block DoH without doing MITM on all outgoing HTTPS? For that matter, how can you block HTTPS based VPNs like OpenVPN? ETA: I understand you can block IP addresses of DNS resolvers that support DoH. I assumed…

IP-based and domain-based. We have a long list of domains/IPs used by VPN providers.

Won't prevent someone from setting up its own SSH-based proxy on port 443, but covers things that are accessible and easy to use by young students (talking about elementary school on our case).

Again, we are talking about a school network with young kids (under 12/13).

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#40
post #23
post #20

Earlier quoted context omitted.

> A corp network should set up their own DoH resolver anyway What good is that is the browser uses their own list? Literally that's what the article is saying. Firefox will force users to use ones that break the top-down approach on how software works. If I set a DHCP option for DoH, and setup my own DoH resolver, Firefox wont care, they will jsut use their list. This also opens up possibilities for selling positions…

You can still administer the machine and change firefox's settings.

Most people roam among multiple networks.

Are you going to change the settings manually after each connection in different network? Most people won't. We already have an automation for that, called DHCP, setting up network specific config system-wide... which Mozilla decided to ignore.

Post reply on HN