It's not a malicious DoH server. It's just any DoH server which is bypassing your Pi-hole and therefore resolves the malicious name instead of blocking it.
That's not the point. Don't you need to hardcode some kind of identifier in order to use your malware's preferred DoH server instead of the user's preferred one (which could have content blocking applied)?
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.
I 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.
I'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.
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.
> 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.
Right now is a transition phase, it is absolutely intended that some other mechanism becomes available in the future which is more resilient. The canary domain provides a clear pathway though for existing Do53 configurations to prevent DoH when necessary.
There's still some specific cases where DoH is problematic, but these are being eliminated over time as the technology matures. As an example of this, split horizon DNS in corporate environments is a good choice. Right now, the only realistic way to provide this is with Do53, so DoH must be disabled, but with Microsoft adding DoH support into the Windows 10 DNS Client, they are likely soon going to also support it on Windows DNS Server, which would enable businesses to make use of DoH internally and to simply set the endpoint by enterprise policies.
DoH is a few different things, but at it's most basic it's transport security for DNS, which is a fundamentally good idea any way you slice it. At some point in the future, plaintext DNS will effectively cease to exist and that's a /good thing/. There are several different implementations of encrypted DNS in the wild besides DoH (DoT and DNScrypt as examples), whichever you choose, any option that encrypts DNS both on your local network and across external networks improves privacy and security.
It takes a pretty long time to transition fundamental protocols like this, but a future where more things are sent across encrypted transports is a good future. Plaintext DNS is incredibly vulnerable, and it's also in an area which isn't heavily visible to most users, which is not a recipe for success.
The 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
Currently, Firefox only has DoH rolled out in the US, so CloudFlare is in that same jurisdiction. Additionally, all DoH providers included in Firefox must meet the Trusted Recursive Resolver (TRR) guidelines, sign a contract to that effect, and undergo third-party audits to ensure they meet the requirements.
This is all publicly documented. As Mozilla rolls DoH out to other regions they will add additional TRR partners and CloudFlare won't be the only choice.
While I'm not glad about the current Cloudflare monopoly on encrypted DNS, and I hope more providers spring up soon, I'm inclined to think that Cloudflare are much better able to maintain privacy and resist government intervention (where possible) compared to any local operator.
The 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.
Yes, 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.
The 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?
> 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.
If 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.
There 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.
I'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?
I 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.
As 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.
>assuming you don't want to implement network level content blocking? //
Who doesn't want that? I have a pihole (and use OpenDNS). Bypassed it all yesterday, as an experiment, to look at an anime site my eldest started using and immediately was hit with a pretty impressive and convincing phishing attempt (mimicking my ISP).
Pretty much all of us on HN seem to use some form of 'DNS' based filtering (pihole, or even just hosts file). UK ISPs offer DNS based filtering as a default (and have to filter some pages by law, and are encouraged to filter others [through threat of law]) ... but a lot of people want that, many many families, schools, businesses.
Certainly I don't want it to be easier for advertising and malware to bypass my chosen DNS-style filtering.
I don't want it and I don't recommend it to my peers. I also don't think DNS-based content blocking is really as popular as the PiHole community would say. I use client-side content blocking like uBO instead, which I imagine is overwhelmingly the more common solution, and it is also more powerful and effective (and easier to use).
UK ISPs having mandatory DNS blocking is a great example of why DoH is important. The user should decide what they want, not the network operator.
Perhaps widespread use of encryption technologies means I can't do content blocking on proprietary appliances like the Chromecast for example. I think that's a necessary evil and I just won't buy such an appliance if it's that big of a problem. Only legislation can really fix that kind of problem anyway, it doesn't really matter whether Firefox implements DoH or not.
Make 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.
I agree with you there, OS vendors should be implementing DoH. Thankfully they are finally getting around to it after pressure from browsers.
Regarding the rest of the DNS infrastructure, I agree there is more work to be done. But I see DoH/DoT/etc as a necessary step and not a "half-assed implementation" that needs to be "fixed".
That'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.
