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

91–100 of 301 posts

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#91

Post by simondedalus »

close04 wrote: post #79
est31 wrote: post #72

Earlier quoted context omitted.

Of course you can lock stuff via enterprise settings so that about:config entries can't be modified by local users, but that takes time to find out and test, while removing the weird non-Chrome browser that's still present mostly for inertia reasons but nowadays only gets used for evil porn is much easier.

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 the latter would be the people in charge of school IT is hopelessly naive.

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#92

Post by bluejekyll »

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 DoH, perceive it as an application level concern (layer 7). In this context connectivity and discoverability of services is the aim, and knowing that the information for establishing connections to those services is correct is important to the foundations and guarantees of applications being built to utilize DNS.

In the application and services context, you may not even want a single set of recursive resolves or authorities for the system. And the reasons are to help ensure the data is focused on what you need in different contexts.

I believe that the network level concerns over DoH are a little disingenuous, and this is because there are many ways to circumvent DNS, DoH isn’t necessary, you don’t even need DNS to establish layer3/4 connections. Fighting over DoH for security that can’t truly be enforced in DNS, seems misguided.

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#93

Post by simondedalus »

AndyMcConachie wrote: post #81
gruez wrote: post #54

Earlier quoted context omitted.

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.

DoH is different because it masquerades as HTTPS traffic. You can block DNS traffic sent to servers configured in custom hosts files, but you can't block DoH unless you either have a list of every DoH server in existance, or block all HTTPS traffic. That's kind of the entire point of DoH. DNS-over-TLS (DoT) provides TLS encryption for DNS traffic, but runs over port 853 so network operators can control where queries…

yeah, they're saying just route to the porn site through the custom hosts file.

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#94

Post by rmdoss »

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.

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#95

Post by dogecoinbase »

raxxorrax wrote: post #42
pas wrote: post #15

Earlier quoted context omitted.

A corp network should set up their own DoH resolver anyway. And/or simply install a cert on their workstations and MITM every TLS connection. Even better corps should only allow TLS that they can successfully MITM. It's basic security. If the endpoint/host can do whatever due to lack of firewall/enforcement, then it doesn't really matter what the network operator wants.

I am no sysadmin but working closely with some. I have never seen any case where HTTPS-MITM helps. Yes, theoretically it does allow us to scan for malicious content in a secured connection. Brilliant, but that are not the attack vectors they are concerned about. So what is left is that breaking up TLS just infringes on privacy and allows for tighter control. The security aspect is laughable. Users are angry that thei…

I am no sysadmin but working closely with some.

Some of your best friends, eh? The point of MITMing HTTPS in an enterprise setting is not inbound content scanning (though that's pretty useful to), it's to prevent outbound transfer of secrets/HIPAA or PII data/financial data, and it's a regulatory requirement for some industries.

Besides, the point of DoH is to move DNS into the browser, which Google also controls, to prevent pihole-like DNS-based ad blocking. Cloudflare supports it because it allows them to lock down one of the few remaining actual distributed systems powering the internet. These companies are not your friends, and you should think harder about their incentives.

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#96

Post by simondedalus »

packet_nerd wrote: post #88
AndyMcConachie wrote: post #81

Earlier quoted context omitted.

DoH is different because it masquerades as HTTPS traffic. You can block DNS traffic sent to servers configured in custom hosts files, but you can't block DoH unless you either have a list of every DoH server in existance, or block all HTTPS traffic. That's kind of the entire point of DoH. DNS-over-TLS (DoT) provides TLS encryption for DNS traffic, but runs over port 853 so network operators can control where queries…

> You can block DNS traffic sent to servers configured in custom hosts files You're thinking of configuring a custom DNS server, which is not related to the hosts file. The hosts file replaces DNS so there would be no network traffic to block. Theoretically a kid who really wants his porn could manually add the name-to-IP entries for his favorite sites to his local hosts file, completely bypassing any DNS based filte…

amusingly, putting enough safeguards in place that kids would do this would actually be providing some good education for kids on the path to hacking.

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#97

Post by tremon »

DDub wrote: post #53
cremp wrote: post #12

Earlier quoted context omitted.

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.

Great deflection, but what should network operators do then? And specifically, network security specialists?

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#100

Post by zrm »

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…

Or you can have the local interface and the cellular interface up at the same time, have the default route through the local interface but have a route to your preferred DNS server through cellular. Then the only traffic you have to pay for over cellular is DNS, which is very small.
Post reply on HN