4 ms·
The issue is with Firefox overriding the system DNS with its own by default, when the system DNS may have content blocking applied and the Firefox default may n
by zrm 6y ago
The issue is with Firefox overriding the system DNS with its own by default, when the system DNS may have content blocking applied and the Firefox default may not.
- shawnz 6y agoI think if the user wants that, they should choose to apply it. Not the network operator. Same as how I wouldn't want my network operator inspecting my HTTPS traffic for malware.
- zrm 6y agoThe user can do whatever they want. It's their machine. But you know perfectly well that almost everybody is going to take the default because they don't even know what the setting does, and end up disabling content blocking when they didn't intend to. And in many cases the user is the network operator. What the browser is doing is taking away the mechanism to set local policy. Ordinarily you hand out the DNS you want your devices to use via DHCP, and they use it. If you move that from the OS to the application and the application ignores the DHCP setting by default, now you've lost the ability to set a uniform policy for all your devices and applications. It becomes an arduous manual process to change the setting in every application on every device, and then you probably miss half of them.
- shawnz 6y agoYes, and I am saying the default should be to use a guaranteed source of truth and not something set by the network operator's policy. Same as how your trusted root CA certificates don't come from a network policy for example. I don't think we should be making a convention of inspecting users' private traffic, regardless of whether it is by default or by opt-in, under the guise of protecting them from malware. DNS has historically been set by network policy so that it's easy for network operators to map hostnames to their local network resources. The point of the design wasn't to enable traffic monitoring or content blocking by altering the results for hosts that aren't under your control.
- zrm 6y agoThe problem is "guaranteed source of truth" doesn't exist. When the network operator is you, or your family/company, you may trust the local DNS to respect your privacy more than you do Cloudflare. Not all names are intended to resolve the same everywhere -- sometimes the local DNS will give the RFC1918 address for a local server instead of the public one, or have a set of local names that are only accessible on the local network. How do you propose to globally resolve the reverse lookup zones for 10.0.0.0/8 et al?
- shawnz 6y agoIf the DNS set by DHCP were only used for local network resources and not internet resources, I wouldn't have a problem with that. That is what it is there for.
- zrm 6y agoThere isn't a bifurcation in the namespace for local resources. Any given name could resolve to a local address or a public one. There isn't even anything requiring a local-only server to have a private address -- it's common to have a public IPv6 address for something which is still only resolvable or accessible from the local network.
- deleted 6y ago[deleted]
- josephcsible 6y ago> you may trust the local DNS to respect your privacy more than you do Cloudflare For most people, their local DNS is someone like Comcast or Verizon, way less trustworthy than CloudFlare. We shouldn't reduce the privacy of the majority of people just to increase it for a small minority of people by default.
- ori_b 6y agoI'm the user and the network operator. Can you give me a comprehensive list of places I need to configure, and notify me when another place software can go around my configuration is added?
- shawnz 6y agoI never said there wouldn't be an increased configuration burden for that kind of setup. There was also an increased configuration burden when we moved to widespread HTTPS, but the benefits outweighed the costs.
- ori_b 6y agoAs a user, what is the increased administration burden for http? Are you referring to the whole CA system being an untrustworthy racket?
- shawnz 6y agoAs a user, what is the increased admin burden for using DoH, assuming you don't want to implement network level content blocking? Basically none. What is the burden for using HTTPS assuming you DO want to be able to inspect and block HTTPS resources at a network level? Very extensive compared to plain HTTP.
- ori_b 6y agoMake the libc resolver do DoH, and drop it from firefox,half the problems go away. The other half of the problems are around defaulting to allowing cloudflare to inspect your traffic, instead of comcast. And the lack of integrity and encryption for the rest of the DNS infrastructure. And the expansion of the complex and difficult to secure x509 certificate regime which we should be moving away from. (Something like gossamer seems to be a big step in the right direction) I want encrypted dns, just not a half-assed hack of an implementation that is going to be impossible to fix once deployed.
- 6y ago
- tristor 6y agoI'm not sure why HN won't allow me to reply to ori_b's question below you, however DoH in Firefox (and in Chrome) have clearly spelled out ways to disable it at the network level for those folks who are network operators and want to restrict it due to interference in filtering or split-horizon DNS. https://support.mozilla.org/en-US/kb/configuring-networks-disable-dns-over-https https://support.mozilla.org/en-US/kb/configuring-networks-di... Someone previously mentioned Pi-Hole. Pi-Hole provides the DoH canary domain in it's default configuration, therefore if you run an up to date Pi-Hole on your network you will have DoH disabled. It is recommended (and there are good instructions on the Pi-Hole website) to set up cloudflared or a similar DNS resolver which implements DoH as the backend to Pi-Hole, allowing it to use DoH when leaving your network but still act as the local network's authoritative name server. If you choose to be a network operator, there are some additional complexities you must think about. For those (majority of) users that choose not to be network operators, DoH is nearly transparent for them and provides significantly improved security and privacy by preventing local cache poisoning, DNS injection, and DNS snooping attacks on their browsing. Additionally, while the default in Firefox is a non-filtering endpoint currently, you can manually configure the use of a filtering DoH endpoint like those provided by CloudFlare 1.1.1.1 for Families if you wanted to do so. Nothing prevents this, and it can be configured via policies network-wide in Firefox using the enterprise policy mechanisms.
- zrm 6y ago> DoH in Firefox (and in Chrome) have clearly spelled out ways to disable it at the network level for those folks who are network operators and want to restrict it due to interference in filtering or split-horizon DNS. I still don't really understand this. Yes, it solves that problem, but how is it not also defeating the entire premise? If you had a DNS server from an adversarial network operator, they could just resolve the canary. So it means the browser's DoH is only secure if you can trust your network operator's DNS, at which point, what was its purpose supposed to be? And the fear is that at some point someone is going to try to "correct" that by removing the check for the canary.
- shawnz 6y agoThe user can choose to ignore the canary in the app's settings (not the default though), or they could ignore it at an OS level. And it is indeed intended to be removed and replaced with a different mechanism eventually
- josephcsible 6y agoThat's not an issue with overriding the system DNS. It's the point of overriding the system DNS. Content blocking by anyone but the user is a bad thing, and if you the user want it, then install uBlock Origin or something.