Live data from Hacker News

DNS-over-HTTPS Policy Requirements for Resolvers

blog.mozilla.org

51–60 of 301 posts

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#51

Earlier quoted context omitted.

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

If DoH is backed by e.g. Google, won't they just end up exposing DoH on the same IP addresses serving www.google.com? Similarly, what if e.g. CloudFlare expose their DoH on all their addresses? This seems like the obvious next step for them.

+1

And Cloudflare already does expose DoH on all addresses, as long as SNI/Host header is one of the vhost hostnames. You can currently make DoH requests to cloudflare-dns.com , the "mozilla" subdomain, one.one.one.one, 1.1.1.1, and 1.0.0.1 (there may be others that i'm not aware of ).

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#52

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 they want me to).

I really like Firefox for they are the only real option these days. I use it and I encourage all those around me to use it. This change will require me to do a lot more manual work and likely lead to confusion over whether a service is down or not.

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#53
post #12
post #4

Earlier quoted context omitted.

His main argument seems to be that the network operator should have control over DNS requests for safety reasons. Control and monitoring. This is the antithesis of privacy and encryption. I wouldn't be surprised if he was pro http over https either.

Because they should! Think a corporate network. If I as a sysadmin set our DHCP options to give out our own resolvers, I expect that every machine on the domain to use ours. DoH breaks that completely; and hence the network operator should have the final say. As a sysadmin myself, if browsers are overriding the basic model of top down, and it hurts me, because when something is wrong, I cant just look on my machine,…

Sysadmins should concentrate on managing and securing the devices and not the network. This is advantageous with todays mobile workforce where users expect the same experience at the office, coffee shop or home.

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#54

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 the bigger problem is that your porn filters can be circumvented with a DNS change. If you're banning DoH, you also need to ban custom hosts files.

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#55

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.

DNSCrypt and other solutions typically involve changes to the DNS resolver in the underlying operating system. That's a lot harder to get changed and deployment can take a long time.

DOH can be implemented directly inside of the web browser application, since those browsers are obviously already doing everything over HTTPS. So the browser developers just have to build in a DNS client. From their perspective, I would see that being much simpler. And deployment is as easy as the next browser application update.

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#56

This has negative implications for security. For instance, one reason why DNS resolvers might block or modify requests is to blacklist domains used for malware operation (botnet C&C domains). Other things like DNS sinkholing and poisoning are also frequently used as tools to disrupt malware communication. In addition, collection and analysis of below-the-recursive DNS traffic is one of the primary ways in which secur…

You can currently customize the trr address in firefox, so assuming you trust a network box's single HTTPS certificate, it can also run a DoH server.

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#57

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…

So the students are advanced enough to change their firefox config but not enough to change their DNS in their computers?

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#58

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.

It sounds like they have root access on the computers in question. There's plenty of options thus available to them.

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#59

Earlier quoted context omitted.

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.

[deleted]

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#60

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…

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

OpenVPN isn't HTTPS based. It has TLS support, but AFAIK it's implemented as TLS-over-OpenVPN rather than OpenVPN-over-TLS, so it's still very distiquishable from a HTTPS connection. There are workarounds like using TCP mode over stunnel, though.

Post reply on HN