Firefox by default directs DoH queries to DNS servers that are operated by a "trusted partner".
That's what I don't want - Firefox offering services.
Once you have a centralized server, with a huge number of minor queries passing through it, the operators get uppity. They start thinking they have editorial authority. Someone will decide that the DNS server should censor something. Child porn is the usual excuse, and then, after a while, you can't see sites that mention Tienanmen Square or Ukraine any more.
I'm quite happy with Sonic's classic DNS server. It just answers DNS queries and forwards requests to the appropriate upstream DNS server as required.
This is configurable though (it's only a default), and is still better than the status quo in a lot of areas. Either you care enough to change it, or you stick to the default. Default (ISP) plain DNS is worse.
The random company in this case is Cloudflare and NextDNS. And using DoH you cut out your ISP from the equation (at least for your browser traffic).
You can also setup a custom DoH provider (that can also be configured on the system level, not just the browser) so neither Cloudflare or your ISP gets your DNS queries.
Cloudflare and NextDNS absolutely counts as "some random company" in this context. I have no reason to trust random American companies more than my local ISP. I don't trust the USA more than I trust my own country.
Even people in Germany who want to read the other side of the war story, like I did yesterday to read RT(.com) vs the Tagesschau propaganda.
Since my ISP, O2, has removed rt.com entries and other russian propaganda outlets (I acknowledge the "west" also has propaganda outlets like Reuters etc) I was looking for ways to still read rt.com news. I looked into Firefox' preferences and searched for "DNS" and saw DNS over HTTP and I could pick Cloudflare, NextDNS (never heard of) or custom. I picked Cloudflare and read rt.com thus getting the other side of the whole bs propaganda mess.
The German Grundgesetz (constitution) says "eine Zensur findet nicht statt" (censorship does not occur/there will be no censorship) yet, there is censorship.
I was sceptical about DOH in general (why do we need this?) but now I see why this can be a good thing and great as well that Firefox supports it so easily.
Because your ISP can block a "raw" DNS request, regardless of what server you configure. Your ISP can even inspect your DNS request, and choose to give a fake response or block the request based on the domain you are requesting.
Because USA wouldn't issue a national security letter to get dirt on foreigners? Seems like if Mozilla wanted to choose DoH as way to protect people from being spied on they wouldn't choose USA-based companies?
Like "don't get caught by your own gov accessing restricted material get caught by USA gov-related organisations so they can sell you out to your own gov & benefit USA".
If you're bothered about who's watching your web traffic then it seems highly unlikely you want to add USA to the list of who is watching you??
There aren't many companies with that capability and scale outside of US.
And the States are watching you anyway: most of the Internet resides there. Even the websites that don't are likely using Cloudflare or etc to save on traffic.
And who on earth is NextDNS? Looking at their website, there's no mailing address, phone number, or other identifying information other than the names of the founders and their Twitter links. If that doesn't qualify as some random company, I'm not sure what does!
And that’s fair, again this is all completely customizable and in fact you are better served configuring a system/network-wide DNS host that you run yourself or trust.
If it is irresponsible to utilize the services provided by companies under the jurisdiction of the United States, then using much of the internet and Firefox itself is irresponsible.
The user made a conscious choice to trust one specific American company. They do not want other companies they did not personally "vet"-- with whatever weird and personal criteria they feel like -- added without their approval. This shouldn't be this hard to understand.
And they have the option to not utilize this feature or change the settings to a service provider they do trust.
The threat vector is understandable. Not making the choice to mitigate it is what does not make sense to me. Cloudflare is not an unknown operator. You can study their past behavior, their beliefs, and how their services work, and make that choice.
Saying 99% of people accept the defaults and claiming this is bad without learning about what the defaults are or how to change them when it takes a few straightforward steps to do so is what does not make sense to me.
Even installing Firefox in the first place is to make a conscious choice to change the defaults of nearly all operating systems that the vast majority of people on Earth use. It’s defaults will also now have a feature to encrypt your DNS queries to a third party vetted by Firefox. If you cannot trust them then why use their browser?
So? That's not an argument for doing it again. 'Everyone else is taking a bung from the NSA to forward them data', for example, isn't a moral justification to do it yourself (made up example).
Your ISP will see every IP you're communicating with. They don't need your DNS at all. Trying to hide your traffic from your ISP without a VPN is unlikely to work.
ISP-provided CPEs often (usually these days? I wonder if anyone has studied this) allow you to change the recursive DNS servers that they forward queries to. Nor do they let you customize the DNS servers handed out by their DHCP servers.
A while back, Sky Broadband was even intercepting all customer traffic to UDP or TCP port 53, and forcing it to go to their shitty DNS servers, which panic and drop the connection when they see something 'unusual'.
> A while back, Sky Broadband was even intercepting all customer traffic to UDP or TCP port 53, and forcing it to go to their shitty DNS servers, which panic and drop the connection when they see something 'unusual'.
This is exactly why DNS over HTTPS is a thing. Unencrypted services are regularly abused by ISPs and DNS is no exception.
Even in that scenario you’re still vulnerable to DNS sniffing and injection. These aren’t theoretical concerns, they’re real-world actively explored vulnerabilities. And if you still don’t care, well, that’s why you can turn DoH off.
Cloudflare has a legally binding contract with Mozilla to this effect. So you’ve traded up from a number of companies that have never promised to not sniff or tamper with your traffic (and often do, and don’t really have any positive brand image to protect) up to a single company that has a legal commitment not to tamper with your traffic (and has some form of brand image to protect). I too, would prefer if DoH had more technical features to prevent sniffing/tampering, but this is an upgrade.
See, IMHO a "binding contract" isn't worth the paper it's written on if violations of the contract are undetectable. There's no brand image impact if there's no evidence.
And if I was an intelligence agency trying place spies, Cloudflare would be among the first tech companies I'd target.
This feature seems almost exclusively a feature for people in the ISP-monopoly-friendly United States.
>And if I was an intelligence agency trying place spies, Cloudflare would be among the first tech companies I'd target.
This seems like a threat model swap in the conversation. The subject threat model here is (1) defending against companies stealing and selling my data. You swapped in the threat of (2) state level agencies spying on you through these companies.
The problem is that #2 seems to be an intractable problem. (but not so much because of an infiltrated DNS provider, more like cable taps and infiltrated hardware manufacturers)
#1 seems to be a more solvable problem (albeit at increasing levels of complexity). When you bring #2 into the conversation, it defocuses on the solution to #1 and gets to a point where we all throw up our hands and admit helplessness and defeat.
I see this happen often and I think every conversation should be clearly grounded in the threat model that is being addressed.
In some countries ISPs work closely with the government and block certain websites the government asks them to etc. In these cases I would trust cloudflare over my ISP
In some countries (USA) tech companies (Cloudflare) work closely with the government (see Snowdon revelations). I trust my ISP, which I chose, more than a foreign company (Cloudflare).
Everyday people who are worried about state-actor threats - an incredibly targeted and unlikely scenario for the average person - but are less concerned about their personal information being harvested for marketing purposes - something that happens all the time to everyone.
> Everyday people who are worried about state-actor threats - an incredibly targeted and unlikely scenario for the average person -
I agree with you that people should be more worried about companies collecting their personal info, but we know now that the state collecting your data isn't incredibly targeted or at all unlikely. They just take everything. It's happening to every last one of us every single day. It's been going on for decades.
And i don't get how one would think that I, as a European, would want an overseas company to handle my data. If my ISP is breaching GDPR, all i have to do is to go to data protection agency (at least i have that option on the table), good luck doing that with an overseas company... I have zero indications that my ISP is selling data for marketing purposes (unlike some US ISPs which even inject ads).
Because if the situation is reversed and e.g. the local police subpoenas your ISP to find people that are "illegally torrenting" or whatever they won't include you. That's happened a lot within Europe.
Even if the foreign government spies more nether jurisdiction is likely to care enough about you specifically to make an international case of it.
In other words I'd think most Americans would be better off proxying through Europe, and most Europeans would be better off proxying through the US.
Even better would be to proxy through a third country that your own country is unlikely to cooperate with, and which won't care about you personally.
E.g. I wouldn't want to live in Iran or North Korea, but I'd think proxying DNS through them would in some way maximize my privacy if I was living in Europe or the US.
I'll never travel to either of them, and my authorities are vanishingly unlikely to cooperate with either of them for anything short of murder.
Except proxying through Iran or North Korea literally puts a target on you locally. Not really the brightest idea.
As for other things - it is not black or white, depends where you are and from that you choose the best option for you. The "copyright" cartels are mostly American so it kinda does not even make sense to use US in order to avoid that, just makes it easier for them.
Running your own DNS resolver doesn't give you any of the benefits that using DoH does. The recursive queries that it sends out are just as vulnerable to an adversary on the network blocking or spying on as the ones sent to a regular insecure DNS server.
I live in China and (still) use Firefox in preference to Google. I agree they need to fire the management and focus on the code. The big pain with DNS is that it's one avenue of censorship but also a proxy for many wrong-headed network geographic assumptions through the lens of geoDNS. "Oh, you resolved from Europe, so you really want a European server! Let me help you out there..." The internet has far too many of these half-baked hacks layered now, it's getting to the point where to obtain a halfway trustworthy response you have to have a dynamic network of geographically distributed and temporally transient nodes seeking similar information and voting on the result. Geoscoping, echo-chamber personalization, household profiling, jurisdiction-second-guessing, ID verification as an outsourced service, political policy fandangling, globe splitting for artificial market segregation, walled-gardening, DRM...
What is a practical alternative to multiple DNS views based on the client's geographical location, for the problems solved by them?
A way to 'opt out' of response customization based on my location would be nice while troubleshooting. But then which zone is that going to give me? Probably the US one. :P
What is a practical alternative to multiple DNS views based on the client's geographical location, for the problems solved by them?
DNS was originally intended to be a domain name resolution service with fixed records. Yet, IIRC even in the very early days (1983) it allowed multiple records. So providing a list of potential endpoints to the client to empower them was fully supported since approximately day 1.
Apparently, instead of developing smart clients that use this (very efficiently provided) information to make reasonable actor-centric decisions, we have developed dumb clients and instead of selecting the best possible endpoint from a set it will just select either a random response or the first response most of the time. GeoDNS further degrades this already bad situation to purposefully provide limited, expiring and non-cacheable responses to individual clients thus locking in the failure.
There are application-level peer selection implementations for various protocols, for example gentoo had a mirrorselect tool which is awesome and torrents will generally prefer fast peers. It would not be that hard to make a smart resolver that did AS-level resolution and cached previously observed bandwidth to make intelligent prioritization decisions without the need to actually actively probe the network. This could even be done at the OS level, transparent to applications.
So choose a different one. You don't have to use your ISP's. The danger is in everyone using the same one, which is what you get if the browser vendors are choosing for everyone.
Better yet, give the browsers a way to detect this (e.g. generate a random domain known not to exist and make sure it gives NXDOMAIN) and switch to the other DNS only if the normal one is broken.
I know that both T-Mobile and Comcast have both ignored user selected non-DoH DNS settings by force in the past, either by DPIing port 53 traffic or static routing major public DNS servers toward their own resolvers.
I don’t really understand this perspective. “Sure, I’m using vulnerable technology, but nobody has exploited me lately that I know of” isn’t a statement that would get positive reception in any other netsec discussion.
yeah... it's not fear mongering when it's a thing that actually happens. Some ISPs collect and sell your data. I mean, they even paid congress to make it okay for them to do it. They sure can't be expected to keep their word
And you really believe that "every ISP" sells your data, only Cloudfare is not doing it ? You know, Apple was a "privacy oriented company" until some years ago.
Well... I said "some ISPs" sell your data, not "every ISP", but I wouldn't put it past any of them. Personally, I don't trust cloudflare, I don't like efforts to kill ad-blocking, and I don't like further consolidating people's DNS traffic into the hands of a smaller and smaller number of providers. I've got the feature disabled for now. I wish someone like EFF would set up a DNS server supporting DoT. I'd pay for the service!
ISPs don't have the best profit margins, especially ones in competitive markets..
If the big players are selling DNS data, I guarantee you there are companies out there approaching every other smaller ISP with a turnkey solution that makes it as easy as possible to do the same thing with some kind of revenue share model.
Not a lot of businesses would turn down extra money like that, when they know their big competitors are doing the same thing.
Unlike most ISPs, privacy and security are a core part of Cloudflare's brand and business model - at least at the moment - so it's in their own interest to actually not do this stuff.
Only time will tell whether or not they pull a "don't don't be evil" on us, but that's a different conversation. :-)
Cloudbleed and particularly Cloudflare's response to it (the way they publicly blamed Google) tells you everything you need to know about how trustworthy Cloudflare is. I personally use Google via DNS over TLS, not that it is a good option but I personally prefer that to the alternatives available near me. CenturyLink was intercepting DNS last I checked a few years ago.
It is much easier to replace Cloudflare if they violate your privacy than to replace your ISP if they violate it. That helps to keep Cloudflare honest.
I guarantee the ToS you agree to with your ISP gives them to right to do this kind of stuff, for "network stability and performance" reasons or some other reason.
I used to have Spectrum "community wifi" (their service for apartment buildings). They were doing this as of last year. They even spoofed responses from root servers, which utterly broke things like `dig +trace`.
No, you don't. I have only one choice of ISP, Comcast. Comcast sniffs all DNS traffic to this day. Their DNS is hard-coded into their routers. I know they sniff because I have gotten DMCA notices while using a VPN. I had to spend quite some time setting things up to my VPN provider's recommendations to be able to use their DNS. I haven't received a DCMA notice since.
And yes, I know a cheap router can easily fix this problem. I just haven't had the time..
Capturing and redirecting DNS traffic is not difficult. You can do it yourself to force smart devices with hard-coded DNS settings to go via a local resolver that filters ads/stalking, so I have no doubt there are ISPs doing it to their customers to keep control for the purposes of tracking and NXDOMAIN hijacking.
Not without DoH. If you just try to set a custom server to use for insecure DNS, it's trivial for your ISP to rewrite all of your insecure DNS queries to go to itself instead.
Didn't the UK run into a problem a decade-ish ago where the group compiling the list of porn sites to block by default included the websites for their rival political parties? I just tried searching for references, but I can't find anything with details. I can't speak with certainty and it sounds like it was just a grunt being a jerk, but still a risk with these types of restrictions.
At the application level, it's happening right now all over social media sites. The risk is too great that our delicate minds, unable to separate fact from fiction, will ingest something deviating from the approved narrative.
Around 2 years ago my country blocked access to change.org as it contains "prohibited content" (it is widely believed to be an appeal for Germany not to permit Thai king to take up long-term residence there; people believe that the ruler should behave properly and stand with the people in its country)
The appeal itself appears to be reasonable, but Thailand is notorious about the enforcement of lèse-majesté law [1], and anything that could be interpreted, even slightly, to fall under this law often saw a summary judgment, less burden of proof, and harsh punishment. This is the reason the authority cited as a basis to block it. AFAIK, the website fought back; the block lasts only 6 months.
In the UK snoopers charter was supposed to specifically target child porn, the actual wording of the law made it legal for your bin man to see your internet history for any reason.
Do they actually use their massive unchecked power to target child porn? We don't know because it's unchecked the government doesn't report on how the law is used it just uses it.
If the government actually used it to lock up a thousand pedos that would be pretty great it would get me voting for that government so why haven't they reported how success-full this law has been in the 4 years its been in affect? we haven't heard a peep, probably because there hasn't been any success for them to boast about.
> Once you have a centralized server, with a huge number of minor queries passing through it, the operators get uppity.
This is currently the case, no? DNS is already, as far as the user concerned, a centralised service where any slippery-slope censoring can (and im sure does) already happen.
As opposed by your "trusted" partner ie. your internet provider? Ignoring that these are the organisations that keep getting hacked, they also outright try to monetize your DNS queries whichever way they can (even falsifying real sites).
And that's ignoring the obnoxious government interference ISPs tend to implement through DNS. From piratebay to youtube blocks.
You have to trust someone with DNS. And Firefox's trusted partner is better than the current status quo.
Can I ask what you would prefer? If FF adds an additional choice among the status quo, are you saying you would prefer the status quo minus the additional option of FF?
Simple: when you use the default search in a browser, you immediately see who is providing search results. If you have a problem with Google, for instance, you see that it's Google and you go and change it.
Mozilla decided to turn on DoH by default, without asking, without prompting, without any indication whatsoever. Even if you configure a canary domain, that doesn't disable the DoH preference - it just temporarily turns it off.
Organizations making unilateral decisions about sharing my private information with an untrusted, for-profit company that has a history of abuse and social irresponsibility is a very bad thing, not a good one.
DNS is not centralized. You can enter whatever DNS server you want. The problem with plain text DNS is that in countries like Turkey over half million domains are blocked in DNS level. Even if you enter your custom DNS, Turkish ISPs MITM the queries and respond with are IP adrress that says that the domain is blocked. DoH prevents such attacks. For this reason once again huge thanks to Mozilla who fights against opressing regimes.
The traffic already flows through their browser. If they wanted to filter content, they could do it now at render time. There’s nothing stopping a browser from doing content analysis before it chooses to display it to you. The fact that they haven’t, is a pretty good sign.
If you're on current macOS/Windows/Linux/Android/iOS/ChromeOS you probably just want to configure DoH or DoT at the operating system level so it is done system wide. The other half reading this probably want a "how to force disable" guide instead of a "how to" guide. The automatically rolled out browser specific method described in this article is really directed at users that don't know this is even a choice and probably wouldn't have an opinion one way or the other if they did.
Somewhat unrelated but Firefox also supports SOCKS proxying independent of the OS config. Combining this with ssh -D and you can effectively VPN your Firefox traffic out any box you can ssh to, including the DNS requests. This has been both useful for me as a troubleshooting tool and as a simple internet VPN.
> Combining this with ssh -D and you can effectively VPN your Firefox traffic out any box you can ssh to, including the DNS requests. This has been both useful for me as a troubleshooting tool and as a simple internet VPN.
You can essentially "VPN" (relay) your in-browser http traffic with just DoH.
Setup a DoH stub resolver to reply with the same ("gateway") IP for all DNS queries, then on the gateway IP, forward traffic by sniffing TLS SNI (http2/http1.1) or snooping the host headers (http1).
This won't / can't work with http3 because defence against ossification (by such middlewares) was one of quic's design goals (http3's underlying transport). You can blackhole all UDP traffic on the gateway though, which should block http3 altogether.
The only real worry is there's no authentication at the gateway. Could impl it with some form of "captive portal", however.
That's really fun and clever :), I love hacking with network protocols like that. Go or JS(Node/Deno) is also how I usually go about it! Is there any place I can follow you at outside of GitHub?
Thanks :) I'm not as active on other social media. I must also point out that my networking chops are at beginner level. midway is mostly adopted from inetaf/tcpproxy and dlundquist/sniproxy.
> Go or JS(Node/Deno) is also how I usually go about it!
Pretty much my choice of languages too. Deno, especially, is a wonderful alternative to Go. I co-maintain a DoH stub-resolver that runs on Node/Deno: https://github.com/serverless-dns/serverless-dns
I believe you can set a different proxy on a per container basis, so you could for example have a VPN container and a work container that send traffic via different places.
> If you're on current macOS/Windows/Linux/Android/iOS/ChromeOS you probably just want to configure DoH or DoT at the operating system level so it is done system wide.
Indeed. The problem is that a lot of operating systems still don't support it at all yet.
> The other half reading this probably want a "how to force disable" guide instead of a "how to" guide.
Sadly, yes. And the only reason I've heard for this is that they want to be able to censor or surveil traffic from other people's computers.
I'm actually in the "how do I force disable" camp for reasons unrelated to other people's computers.
On my personal network I've got an inside view of my domain that will resolve internal services if you hit the resolver from the inside, this breaks if an external resolver is used and it'd be more work for no real gain to set this up as an internal DoH resolver and make sure clients used that.
On my work laptop I have a similar need for split resolution in many cases, particularly when connecting to customer's networks. I also have an additional need to be using the same resolution flow as their computers when troubleshooting, if one of their DNS servers is misconfigured I'll never see the issue resolving to an external server.
I've not found the browser fallbacks to fully cover the 2 above scenarios and, even for the parts that are covered, I've not seen it be particularly reliable. Particular if you switch networks often.
I've also seen people against browsers pushing users to fewer centralized services but I'm not really in that boat myself, I point DNS to 1.1.1.1, 8.8.8.8 anyways.
That said I run across a lot of customers that don't understand it's easier to build and enforce a proxy config on a managed fleet than to try to play whack-a-mole with every user packet that doesn't match this policy and try to avoid DoH at the network layer as a result. I don't really expect this to change until security auditors stop accepting these implicit policies as meeting requirements. Outside of finance/government that still seems forever away.
> I'm actually in the "how do I force disable" camp for reasons unrelated to other people's computers.
I think you're actually just in the much smaller but perfectly legitimate "how to disable" camp, rather than the evil "how to force disable" camp, since you're not trying to keep someone who wants to use DoH from using it.
> On my personal network I've got an inside view of my domain that will resolve internal services if you hit the resolver from the inside, this breaks if an external resolver is used and it'd be more work for no real gain to set this up as an internal DoH resolver and make sure clients used that.
Do the domains in question resolve to other IPs on the outside, or do they not resolve at all? If the latter, then Firefox will automatically fall back to local DNS when DoH fails to resolve them. If the former, then I can think of three other solutions that don't require disabling DoH altogether: either switch from split-horizon DNS to NAT reflection, configure Firefox to disable DoH for just that domain and its subdomains, or add IPv6 addresses for them since it doesn't get NATted.
> I also have an additional need to be using the same resolution flow as their computers when troubleshooting, if one of their DNS servers is misconfigured I'll never see the issue resolving to an external server.
I agree that this is a legitimate reason to turn off DoH for yourself (assuming that your customers don't use it themselves, of course).
> I think you're actually just in the much smaller but perfectly legitimate "how to disable" camp, rather than the evil "how to force disable" camp, since you're not trying to keep someone who wants to use DoH from using it.
Yeah not other people's setups (not sure how to do that but it's an interesting question actually, maybe dynamic FW rules trigger by the local resolver's responses?). "How to force disable locally" would probably be the precise term. What I mean by that is network.trr.mode has 5 settings:
- 0: Off by default
- 1: Reserved (previously used for deprecated functionality)
- 2: Secure resolution first
- 3: Secure resolution only
- 4: Reserved (previously used for deprecated functionality)
- 5: Off by choice
and defaults to 0, disabled which may automatically switch to 2 on you in certain circumstances. I switch it to 5 which forces it to stay disabled regardless if Firefox rolls it out automatically in my region or thinks DoH would work correctly in the currently connected network or changes how detection/deployment works in the future.
> Do the domains in question resolve to other IPs on the outside, or do they not resolve at all?
Different, apart from avoiding needing external NAT+FW rules for an internal service my LAN is 10G but my NAT capable router is still only 1G which can surprisingly make a difference pulling files or accessing KVMs and so on through my personal portal.
> If the latter, then Firefox will automatically fall back to local DNS when DoH fails to resolve them. If the former, then I can think of three other solutions that don't require disabling DoH altogether: either switch from split-horizon DNS to NAT reflection, configure Firefox to disable DoH for just that domain and its subdomains, or add IPv6 addresses for them since it doesn't get NATted.
Or just set DoH to force disabled Firefox and avoid rebuilding my network around something that nets me no gain. My external name resolution is already secured, my internal services already work, and I'm already using the most performant path. The only thing I need to set is network.trr.mode to 5 and I'm golden as Firefox .
> If the latter, then Firefox will automatically fall back to local DNS when DoH fails to resolve them.
As stated I've not found the fallback detections to be foolproof. E.g. on top of split-view DNS some organizations point a wildcard record to their landing page meaning any request to the domain always successfully resolves.
Yes, if you're just setting network.trr.mode to 5 on your own systems and not trying to interfere with other people's usage of DoH, there's nothing wrong with that. I'm glad to hear that's all you're doing.
In that case, you can just disable it the normal way on your devices in their end-user settings. That's still not a reason to try to block it at the network level.
Also, it's a bad thing if you have a reliable way to block any device on your network from using DoH, because then you'd have a way to block other people's devices from doing so, and so would the rest of the adversaries who want to censor people.
>Indeed. The problem is that a lot of operating systems still don't support it at all yet.
Which one exactly? Android has it called "Private DNS", Linux supports it with systemd-resolved, Windows 10 too (don't know the build number at which it starts). Apple with OS 11 and iOS 14.
The main issue I see is that there is no support for both in every OS. "Private DNS" is DoT, while Windows 10 support is DoH. Apple has both.
DoT is worthless since it's so easy to block at the network level, so I'm not counting Android. And doesn't Windows 10 only support it if you're in the insider program?
Depends on the client. You can construct any viable scenario here, won't matter. Right now you can block DoH too, simply by blocking Cloudflare, Quad9 and Google.
> The automatically rolled out browser specific method described in this article is really directed at users that don't know this is even a choice...
So it's intended to benefit 99.9% of everyday users, then, despite the risk that it might irritate the 0.1% who for whatever reason want things configured some other way. Sounds like they made the right call.
Meh. I run dnsmasq combined with a dns to doh proxy on my router, and I only do that to hide my DNS queries from my ISP, but this is probably paranoia on my part because AT&T ultimately knows the IP of every site I connect to, and I guess I don’t care enough to run a VPN full time. When I do care, I’ve got a droplet running wireguard at my disposal.
> this is probably paranoia on my part because AT&T ultimately knows the IP of every site I connect to
There's a privacy benefit anyway for some sites. If your browser also supports eSNI or ECH, and you're connecting to a site hosted behind a CDN like Cloudflare, your ISP will then only know that you're connecting to the CDN, and not which site behind it that you're visiting.
You can rub it on WSL2, tell it to listen on 0.0.0.0 and set the WSL2 IP address as the windows’ gateway.
It’s slightly more work, but works quite well for any TCP connection; I’ve actually had 20 windows machines use one Linux machine this was as a poor man’s one way VPN at some point (not recommended to replace a real VPN, but in that case it saved a couple of weeks of calendar time and got the job done)
It's not quite as secure as having a password, but you can force the proxy to listen on localhost-only (or any other specific addresss) by specifying it along with the port:
ssh -D 127.0.0.1:8080 some-host.elsewhere.example
This won't protect you from people who already have access to your host, or from people standing behind you, but at least folks on your network can't use your proxy.
This is objectively a terrible decision. Technologically, politically, culturally. We had a very good design in DNS, and people are throwing it away because they're terrified about the potential that their ISP might use their data. Never mind that Netflix already does it to them when they watch TV, Target does it to them when they buy condoms at the store, Google does it with their mail and search results, ESPN does it to them when they play fantasy football, and Starbucks does it to them when they buy their venti mocha frap. But because Comcast might also know what they do in their private life, we should ditch one of the internet's most important protocols, and give all our data to Cloudflare, a central TCP-based US-owned DNS resolver.
Nobody in the world needs DNS over HTTPS. If you actually need to hide your DNS requests, you have bigger problems that you need a real VPN for. This is a unilateral political decision by the people who have the most power over browsers because they have an emotional obsession with privacy, even if it makes technology in general worse.
This isn't emotional. People deal with censorship by their ISPs or absurd fines for petty piracy literally every day. It's actually more accurate to say that you have an emotional attachment to a particular internet architecture compared to the practical advantage that most people have if they have their traffic encrypted through an American company, which is a big step up from local ISP snooping in a large chunk of the world.
It's also not a 'unilateral decision by people who have the most power', it's an optional offering by Firefox, a non-profit open source browser with less than 5% marketshare. You're making it sound like the Illuminati just came up with this
The thing is, DoH doesn't solve either of those problems. Your ISP can still censor your traffic unless you're using a VPN (in which case you don't need DoH to protect from your ISP), and ``piracy'' happens outside the browser, so again, unless you're using a VPN (in which case you don't need DoH to protect from your ISP--and even if you did, DoH in your browser won't do anything) you'll still have to deal with the absurd fines.
And let's not forget, ISPs can just block known DoH hosts, and now that weird browser you were trying doesn't work anyway. Oh well, let's go back to the corporate backed spyware we're all familiar with.
This is a Bad Idea, and has the potential to make Firefox unusable to exactly the people it's trying to protect.
You cant ban cloudflare without blocking half the internet.
Part of the problem is that many ISPs use Akamai for dns, and they have a broken malware filtering algorithm that causes a lot of false positives, resulting in sites being blocked for no reason, and there is no way to get whitelisted [1][2][3]. DoH has been a lifesaver for us.
In the case of a site using cloudflare, the ips will resolve to cloudflare, so impossible to block without blocking all those sites. Dns and the web traffic both use https to a cloudflare ip.
As much as Ive complained in the past about cloudflare harbouring spammers, I have now come to the conclusion they are providing a very important service. It certainly saved me a huge amount of stress when our site was blocked as a false positive by akamai’s dodgy dns, which meant customers from a whole raftload of isps couldnt access our site. Not to mention the benefit to users in countries like Russia.
If Google actually cared about this, why bother going through the faff of making and standardising a new protocol?
You don't need a "DNS Standard" to be able to do name resolution between a client and a server you control. Just make up your own, pick a network transport (HTTPS works in most places!) and deploy it without telling anyone.
I don't follow what connection that has to Firefox. Seems like Google already comfortably solved their problem with Chromecast without needing a standard or anyone else to implement it.
Like IBM patenting everything that any of their employees ever stumbled upon there is value to controlling and defining standards (both inside and outside of tech).
But if every application and hardware appliance is using its own DoH settings, instead of doing the expected thing and getting its DNS settings from the system, using a PiHole becomes increasingly difficult.
Sounds like what I need is a VPN or Tor in these cases. To such regimes if FF provides a way to bypass their restrictions FF would end up being classed contraband similarly.
Tor is actually worse in this regard. E.g in Russia public Tor bridges are blocked, so you can't connect to it without extra steps. Some public VPNs are blocked too.
But DoH makes the price of blocking a single domain too high, for example, if Cloudflare were to use it, the only way would be to block every service that uses CF.
Okay, so I’m an oppressive state that has the wherewithal to block Tor but I’m not going to block DoH, because “the cost is too high” when I could previously mine DNS for free? I think I’d be blocking it and my citizens use a fork of FF that doesn’t force DoH.
You misunderstand what making the cost too high means. The goal is to make it so the only way to block DoH is to block all of Cloudflare and Google, and maybe eventually all of AWS and Azure too.
No that’s what I understood you meant by cost alright, and notwithstanding many regimes being able to pay just that, it’s hardly the case that prohibiting the use of DOH you’re going to be blocking those sites.
Perhaps, but the idea is to take the lead- and thus when all other browsers ,or most of them ,adopt this, that will be a little trickier to classify every browser in this manner.
Overall, this will have an impact in the many regimes- and perhaps is one of the best methods of doing so.
While it is still ...having faith in Cloudflare(one could audit them, but of course the question is how by-nature are they built to resist threats from APTs to the US gov coming knocking for info on Snowden or a similar person, looking for possibilities of compromise) -
I think of the Ukraine Starlink situation-
Overall, the Starlink terminals can be targeted by their signals, - but there's so many ,that Russia would need to do a massive ASAT campaign, or start spam detonating kiloton/megaton warheads in space to really try to disable Ukraine's ability to communicate even when all other networks get cut off, or isolated. And they mgiht be one of the very few capable of that type of escalation, but right now they're getting stymied by groups that are en - masse, accessing something that makes it harder to control, deny info, influence and crush them.
Overall a net positive, but with drawbacks- but their overall situation and ability to choose how they want to operate is increased.
VPNs and TOR are gaining popularity, but this covers those who wouldn't be able to use or figure out those for whatever reason, but who can use a web browser.
I think i've seen the Cloudflare CEO around - i wonder if any cloudflare employees will comment on the risks i mentioned before(centralized source providing availability, US GOV deciding to take interest...)
Firefox actually can solve this- by attempting to pursue deals with more than Cloudflare and NextDNS
The big difference between malicious behaviour of the ISP vs malicious behaviour from all those example companies you mentioned is that I can choose not to use Netflix/Google/ESPN/..., while I can't choose ISP. So yes, I need DoH to protect me from my ISP (and no, full blown VPN is not an option, too many compromises).
> We had a very good design in DNS, and people are throwing it away because they're terrified about the potential that their ISP might use their data
It's more about censorship by governments. Even here in Europe, we have such censorship - against "terrorists", pirates and Russian propaganda. I don't object to censoring Russian propaganda and actual ISIS/AQ-style terrorists away, but censorship against pirates is just enforcement for the ultra-rich.
I think encrypted DNS as a default is a good thing and swapping (with a notification to let you know what they did, why, and an easy button to revert the setting) in an update would be great.
> We completed our rollout of DoH by default to all United States Firefox desktop users in 2019
Why did this setting change for me today mid-session? Did someone malicious use this functionality to change my settings outside of the context of an update? I don't want anyone to be able to remotely change my privacy settings. Knowing this feature exists makes me extremely uncomfortable and has broken my trust in my browser.
Same here. Anyone here have any good arguments for why Mozilla should implement changes like this outside of a version upgrade? I just got the prompt on a version of Firefox that is not the latest version. At first I just tuned it out; it's very easy to think it's some banner on the page annoying you unless you're actively looking for it. Or maybe a notification or location request. I then thought my Firefox installation had been upgraded without my consent, which alarmed me briefly.
And I don't mean just arguments focused on benefits to Mozilla, like it's easier for them, it lets them run experiments, etc. I mean arguments why they should, in the process of doing this, take away my ability to make informed decisions as the owner of my computer. If I choose not to upgrade something, it should not change its behavior in a significant way like this.
Yeah, I've been wondering this too... I've disabled a lot of things like experiments/normandy and telemetry so I'm wondering what I'll have to find and disable now.
I went to the effort of setting up a pihole, and pointing all the devices on my network to it.
When I saw this notification for the first time yesterday I was a bit annoyed - do I now have to think about every application ignoring OS level settings and using its own?
Yes, I use ipset on openwrt to block all known public DoH IPs. That is still not enough. You need custom DNAT rules to forward all queries to port 53 to your local resolver (at my home at least, Google and Garmin devices insist on using their own DNS servers)
I see a lot of people who do no like this. And that is totaly fair. I do not want or need this either, I have my own resolver on my pi-hole and why the f whould I want FF to mess with that.
However, for 'normal' users, this is actually an important an big improvement imo. You cannot expect everyone to understand how it all works and how to run a dns server. If you can, you might not be the target audience for such features.
That being said, I'd prefer my FF without all the 'services' and bullshit. I tried Librefox, but couldn't get it to run. Gave up after 30s. Guess I'm not the target audience for that and I'll deal with disabling mozilla's spam ;)
One problem I've found when trying to switch to an alternative DNS provider is that e.g. different parts of Akamai's CDN servers have different peering arrangement with ISPs and Akamai uses DNS for directing you to a server that is well-connected to your current ISP.
So when using an alternative DNS server, download speeds for anything hosted by Akamai would always slow to a crawl in the evening because I got directed to the wrong set of Akamai servers.
I just got this automatic up/down/side-grade. DNS to be handled by a partner service provider, so they get all my data instead of my ISP getting it? Doesn't seem like an improvement. I think I will turn this off.
> DNS to be handled by a partner service provider, so they get all my data instead of my ISP getting it? Doesn't seem like an improvement.
It's an improvement in two ways. One, the DoH provider will only know that your IP address looked up certain hosts, unlike your ISP who also knows the association between your real-life identity and your IP address. Two, most ISPs (especially in the US) have horrific privacy policies and practices compared to the DoH servers.
What kind of contracts and understandings do we have with Cloudflare? What do we know about them aside from the fact that they protect scammers and spammers?
> What do we know about them aside from the fact that they protect scammers and spammers?
We know their DNS services have very transparently stated sound privacy policies that have been regularly audited by 3rd parties to verify compliance to promises made to users as well as Mozilla and APNIC which they partnered with for this. The worst finding to date from multiple years of service was Cloudflare did not initially mention 0.05% of all network packets in their network are temporarily logged to disk via sFlow sampling to help detect/manage DDoS and that would mean some DoH packets source IPs would be stored on disks during the time not just completely in RAM. I work at a network VAR, I've never seen a DNS resolver with an equally good privacy policy that is actually backed up by 3rd party verification. I have seen endless ISPs sell user data or abuse DNS for additional income and clearly state this in the very service contracts that specify you as the paying customer.
I mean it's your prerogative to dislike Cloudflare and not use them but when they have blogposts directly responding to "We knew there would be skeptics. Many consumers believe that if they aren’t paying for a product, then they are the product." https://blog.cloudflare.com/announcing-the-results-of-the-1-... the questions in your comment speak more to what you'd like to believe than what we actually know.
For example: Their contact information is in WHOIS for countless domains. If you send an abuse complaint to the address in WHOIS, you get a form response telling you to fill out a form on a web site, which is clumsy, slow, has tons of errors, and basically makes the whole process time consuming and arduous.
The form response implies but does not state that they ignore abuse complaints unless abuse is reported in their shitty web form. I asked repeatedly for clarification. They answered with bullshit and sidespeak and WOULD NOT ANSWER DIRECTLY for months.
In a nutshell: they don't want you to report abuse, and they make it hard on purpose, and they're assholes about answering simple, direct questions. Why? Because they make money from spammers and scammers.
They've told me that phishing sites they host that claim to be Adobe ("Flash Updaters") or Bank of America are exercising "free speech". They just don't want to be bothered.
And the whole "We don't host" bullshit: if you provide services on the Internet that contribute to stuff on the Internet working, and if you stopped providing those services, that stuff would stop working, YOU'RE HOSTING. It doesn't matter if it's just DNS, or if it's a caching proxy - you're still facilitating services on the Internet. But just listen to their absolute bullshit about how they "don't host", and you know they're shitty people.
That doesn't even touch on how they're intentionally stratifying the Internet by putting CAPTCHAs on everything and blocking the poor half of the world, and how, if they had their way, they'd be a monopoly that would re-centralize and completely stratify the whole planet...
If you're in the US, whatever you think your contracts and financial relationships say, your ISP is highly likely to be monetizing your DNS lookups already. It's hard to do worse than ISP DNS (and ISP DNS passive monitoring).
Is it known that the partner service provider is Cloudflare? At least that's a recognized organization, instead of a mysterious unnamed one as the Mozilla announcement made it sound. When that happens we have to assume the worst.
While I disagree, I support you having the right and ability to disable DoH on your own devices anyway. I just don't want middlebox operators to be able to forcibly prevent other people from using DoH from their own computers.
I got the pop-over notice for the first time today as well... I'm wondering now how they did it. I have firefox set to notify me about updates, but this wasn't that. I have telemetry/Normandy/experiments/etc disabled. I hope I can find whatever I have to disable to prevent settings being remotely applied to my browser outside of updates
That mostly defeats the purpose though, since to your ISP, a DNS packet from Firefox and a DNS packet from your local DoH server both look the same. Now if you hosted it on a VPS or something instead, then it would definitely be worthwhile.
If you're a dev who uses curl / requests / HTTP libraries, just browser-level DoH isn't enough for ISP privacy or govt censorship evasion.
On Ubuntu 18, I installed "dnss" at the OS-level to send all DNS requests as DoH. Currently, it just forwards them to CloudFlare's DoH URL. But I can also install it as a DoH proxy on my remote server if I want to move away from CloudFlare.
It works fine and is easily installed without any builds or PPAs. The only problem with it is that I had to disable systemd-resolved first to reserve port 53 for dnss.
It is amusing that in Europe, there is this big DGPR drama playing out about websites embedding resources from US companies. Like Google Fonts, Tweets and Facebook like buttons.
Yet the browser sends each and every website the user visits to a US company.
All in all, I tend to think that it is a net positive.
Downside: Now one US companies gets all my DNS queries. But can they stitch them together? I tend to think they can't easily. And will hopefully not keep enough logs to do so later.
Upside: My ISP and the cafes and hotels I visit do not get the info which websites I visit.
The protection could be made even stronger if the browser would send 5 DNS requests for every IP it needs. So if you visit news.ycombinator.com it additionally sends 4 random hostnames to cloudflare.
> It is amusing that in Europe, there is this big DGPR drama playing out about websites embedding resources from US companies. Like Google Fonts, Tweets and Facebook like buttons.
> Yet the browser sends each and every website the user visits to a US company.
DoH is only enabled by default in a handful of countries, and in each country the default resolver is different. In all cases it's customizable. In no case, is it sending European user's traffic to the US by default.
There are European based resolvers that offer DoH endpoints you can use, one of the better options is Quad9, which is a European company domiciled in Switzerland.
I think your concerns about data jurisdictional issues are overblown considering that Mozilla is being careful to do address them as part of their rollout strategy.
> The protection could be made even stronger if the browser would send 5 DNS requests for every IP it needs. So if you visit news.ycombinator.com it additionally sends 4 random hostnames to cloudflare.
I can’t find it now but forever ago there was a tool/project that more or less did this. It would purposefully flood your history with random entries meant to confuse advertisers.
I mean honestly, Cloudflare probably gets a large chunk of your actual browsing traffic too. Giving them access to my DNS queries seems a pretty low concern to me.
I use pihole configured with nextdns DoH as primary upstream server and cloudflare as backup. So all devices connected to the network end up using DoH. Works very well.
In addition, if you configure tailscale on your mobole devices, they can still use your pihole+nextdns/cloudflare even when roaming over 4g.
I have a Pihole set up as my DNS resolver on my home network. My understanding is that this blocks ads at the DNS level. So if I it anyone in my family enabled DoH this would defeat the Pihole services? Can someone confirm this?
Yes, DoH bypasses the Pi-hole. If you want to use DoH and still block ads at the DNS level, then instead of using Cloudflare, use someone else's DoH resolver that does block ads.
DoH creates a precedent where parents are not able to easily control the internet access for their kids. It is fairly easy to setup the router these days and block porn,gambling,malware,social media. Not to mention the OS level config on devices to use a particular DNS server.
Now, we (parents) need some remote management OSS (like in a corporate world). I want to ensure the config of the laptops,tablets,phones does not use DoH but only the DNS of the PiHole.
The point of DNS-over-HTTPS is to protect users from censorship and surveillance by their network operators. Does anyone have any reason to try to block it on their networks (not just wanting to turn it off on their own devices), other than that they're network operators who want to be able to censor and surveil traffic from other people's computers?
>Does anyone have any reason to try to block it on their networks (not just wanting to turn it off on their own devices), other than that they're network operators who want to be able to censor and surveil traffic from other people's computers?
I do.
You're absolutely correct that some folks want/need to be concerned about censorship/surveillance by their network provider(s).
I do not, and if I did, I'd go full on VPN to avoid their intereference/spying.
That said, there are various devices on my home network that are not fully under my control like streaming devices and "smart" TVs. That could also, presumably, extend to various bits of software that try connectng to sites of which I do not approve.
As time goes by, more and more devices will integrate DNS-over-TLS/HTTPS whose resolver settings are hard-coded and can't be disabled.
I want to be able to audit (and block) DNS lookups by all devices on my network.
As such, I use both a DNS filter (ala PiHole) and a local recursive resolver.
Yes, my ISP can see all the DNS requests my local resolver makes, but then they can see all my traffic anyway.
IMHO, DNS over TLS/HTTPS benefits the big DNS providers (since most folks will just use Google/Cloudflare for such stuff), giving them (especially Google) unprecedented access to browsing and other internet application traffic.
For me, at least, I'd much rather have my ISP see the cleartext UDP packets that my local resolver generates than give Google/Clouflare a list of every IP address to which I might wish to connect.
That's not to say there isn't a use case for DNS-over-TLS/HTTPS, but that's not my use case.
Edit: Changed emphasis from local to local recursive resolver.
> As such, I use both a DNS filter (ala PiHole) and a local recursive resolver.
Next step is to ban all network connections that were not resolved using your local provider (and only allow them only for TTL)... also run each low-trust application in it's own container with individual network IP.
For devices that aren't fully under your control despite you owning them, couldn't they still do whatever they want by hardcoding the IPs of whatever services they want to talk to, instead of using DNS or anything like it at all? Blocking DoH doesn't fix that problem.
>For devices that aren't fully under your control despite you owning them, couldn't they still do whatever they want by hardcoding the IPs of whatever services they want to talk to, instead of using DNS or anything like it at all? Blocking DoH doesn't fix that problem.
That's absolutely correct. And if any of my devices were doing that (and I've checked, for just that reason), egress filtering can handle blocking such connections just fine.
Presumably there's a reason that you give these devices Internet access in the first place. Can't they just use the same host for their nefarious activity that they do for their legitimate activity?
>Presumably there's a reason that you give these devices Internet access in the first place. Can't they just use the same host for their nefarious activity that they do for their legitimate activity?
You make my point for me.
Which is why hiding DNS traffic in https traffic is so insidious. Nuke DoH from orbit. It's the only way to be sure.
I haven't really seen many attempt to _block_ DoH on their networks. After all it takes some really advanced methods to do that reliably since it is literally https on port 443 and can be hosted on any web server. I have seen places send signals to disable it for reasons other than censorship or surveillance though, typically because of split-view DNS. There are other ways to solve that but setting the canary domain serves as a quick patch for automatic DoH users who were unaware and anyone explicitly forcing DoH to always on on their own device can usually be expected to work around the problem themselves.
How hard can it be for Firefox to embed its own recursive resolver that talks only to the root servers? If you are really concerned about privacy that’s the only way to go. Other than that it makes little sense to me to trust one company over another.
This wouldn't solve any of the problems that DoH does, because DNS queries issued by a recursive resolver are themselves in cleartext and so vulnerable to a hostile network.
Funny, I reported a bug to Mozilla about their NextDNS offering being mis-configured, and it leaked DNS queries. I turned it on by going to Preferences > General > Network Setting and then fired up Wireshark, and all the queries were sent in the clear, even with NextDNS set to 'Enabled'. They seem to have fixed it. Lesson here: sniff your network traffic and don't blindly trust that DoH is configured properly.
Does anyone know how well modern DoH infrastructure works with geographically specific results? E.g., google.com on any "real" DNS points me to a google proxy on a nearby ISP, usually mine -- netflix also has local ISP boxes.
Don't see how this can work unless Cloudflare/NextDNS is all knowing about the world DNS infrastructure.
Part of it is doing a test DNS query to a canary domain to see if it's intercepted, but the domain is use-application-dns.net, not an actual adult domain.
Why would a parental filter modify or otherwise interfere with use-application-dns.net? I'd have thought a filter would pick up the DNS request, see that it isn't on the list of adult-only domains and pass the request along.
I imagine the idea is that any DNS-based filtering tech would also block use-application-dns.net. An ad-hoc spec. Kind of like how captive wifi portals "block" (or allow) canary domains like captive.apple.com so the OS throws the captive portal login dialogue.
... and the DNS-over-HTTPS providers that come with Firefox / Chrome censure DNS as they like, very obvious now due to our east friends news sites being blocked
that being said, I use this at my work machine so that the local IT agent cannot access the DNS resolver cache
I had problems accessing RT from Romania because our ISPs blocked it (something that is uncommon in this country). I chose a DNS server from the Firefox config page and managed to get it. Really great feature.
I am surprised Mozilla is pushing for DoH. I was expecting Google to lead the front since most of their revenue comes from ads and the DNS-level ad blockers are easily defeated by DoH.
DoH in your browser will bypass your Pi-hole. If you set up cloudflared on your Pi-hole, then it will do DoH itself, so you could turn it off in Firefox and then get the best of both worlds.
Can you elaborate on why you think DoT is better than DoH? Aside from DoT being easier for an adversary to block (which is really bad since blocking it forces a silent fallback to insecure DNS), what material differences are there between them?
I think it's a better choice because it's less complex and avoids "useful features". Bert Hubert goes through most of the points in this talk: https://www.youtube.com/watch?v=pjin3nv8jAo
> Aside from DoT being easier for an adversary to block
HTTPS is also TLS. On the surface of things it's just a matter of two different standardized ports.
> ...since blocking it forces a silent fallback to insecure DNS
An extra (encrypted) configuration point in the form of a pathname, DNS privacy servers can use this to offer you a distinct feature set e.g. maybe you want them to blackhole ads but not porn, another user wants no porn 'cos they're worried about their kids, and I want full fat. NextDNS offers this I believe.
Error messages aren't restricted to what can be expressed in DNS itself. So instead of NXDOMAIN the error can tell me myblanket.example was blocked because it's an advertising source, or that gooogle.example wasn't found but maybe it's a typo and I should try google.example ?
I prefer DoT over DoH. I'm not getting into a discussion of "technically better".
> ...DNS privacy servers can use this to offer you a distinct feature set e.g. maybe you want them to blackhole ads but not porn
No, I don't want any that. I want DNS between my resolver and the remote to do only what it's intended for. I don't want that specific leg of the communication to involve any features, bells or whistles.
DNS over HTTPS is a trojan horse to allow application developers to subvert the system administrator's DNS policy. Specifically, so that companies like Google, Microsoft, Amazon can ensure that you cannot prevent ads being displayed in their little black boxes (hardware or software).
This is dangerous, anti-user, and should be avoided at all costs.
DNS over TLS is the correct and appropriate solution here.
You can ensure your (Firefox) browser does not use DNS over HTTPS by configuring a canary domain: https://support.mozilla.org/en-US/kb/canary-domain-use-appli... but let's be clear here, nobody besides Firefox is going to respect user choice about using DoH.
DoH and DoT both hide DNS requests from the sysadmins. If the sysadmins want to capture DNS for some reason, they can just provision their own DoH server (I do that with my Pihole) or disable the feature all together with a simple canary domain (https://support.mozilla.org/en-US/kb/configuring-networks-di...) in the local DNS resolver.
Although I hate the idea that everything must now be layered on top of HTTPS because shitty middleboxes can't deal with internet protocols, I think Oblivious DOH is superior to simple DoT. It not only provides security, but also anonymity in DNS requests. I'm not sure if that's what Firefox actually implements by default, though.
Chromecast doesn't respect any settings and only communicates over TLS (and some local broadcast protocols for compatibility). If you don't like that, don't buy a Chromecast.
I've managed to get it to use my PiHole by forwarding all outbound traffic to UDP/53 that's not coming from my PiHole to the PiHole itself through a DNAT rule in Firehol:
ipv4 dnat to "${pihole4}" proto udp dport 53 src not "${pihole4}" dst not "${pihole4}" inface not "${world}"
ipv6 dnat to "${pihole6}" proto udp dport 53 src not "${pihole6}" dst not "${pihole6}" inface not "${world}"
So far, I haven't seen any weird traffic that's trying to bypass this rule, but honestly, I don't really care. Whenever I block any of its domains I just get weird error messages about connectivity problems, or a non-working Chromecast. The real meat is inside the TLS connection anyway, and I can't block that.
You can't buy a closed-source, always-online Google product and expect it to let you block it. If I wanted that, I would've disconnected it from the internet or just used a Kodi box instead. We've lost to ability to introspect and filter connections the moment we started switching to TLS. If you don't trust a device, don't install it in your network, that's my take.
The chromecast is proprietary anti user software/hardware. Stallman has been warning about this for decades. DoH has very little to do with this. The Chromecast could hardcode the Google dns server already.
> The Chromecast could hardcode the Google dns server already.
Could nothing; Chromecasts have always hardcoded Google DNS AFAIK. This is a right pain when you want them to stream something from an internal site that has a perfectly good DNS entry but not a public DNS record, and we ended up casting things that used raw IPs because of it. I've also seen some people end up having their router rewrite packets from 8.8.8.8 to their own DNS, but that might actually be more icky IMO.
> I've also seen some people end up having their router rewrite packets from 8.8.8.8 to their own DNS, but that might actually be more icky IMO.
It is actually very simple, just dst-nat everything destined for any ip, 53/udp, 53/tcp, to your resolver, except traffic originated by the resolver itself. Works very well.
> The Chromecast could hardcode the Google dns server already.
This wouldn't work, because routers/firewalls can easily rewrite the destination of insecure DNS queries. But what it could do is to hardcode all of the IPs of the servers it really wanted to talk to, instead of using DNS at all.
It doesn't need to use DNS at all. As long as it can rendezvous through some IP, it can just tunnel all of it's discovery stuff through TLS, or anything else it wants. This is a particularly silly cat-and-mouse game that network pentesters have been winning for decades; it's only because DNS people had a strange heyday as botnet hunters, and botnet authors are really dumb, that this folk wisdom about the importance of DNS policy set in so firmly.
Which is a big downside of DoT and reason to prefer DoH. The people that have an easier time blocking DoT are the very people who are the reason that you'd want to use it in the first place.
This is sort of like claiming that the spread of encryption is bad and dangerous because it provides tools to terrorists. The problem with the claim is that even if every person or organization producing end-user software stopped developing or supporting DoH, the cat is fully out of the bag. It's just technology at the end of the day, and any company making hardware that wants to hide their DNS requests is completely able to do so already. Some are even building VPNs into their IOT devices. This can't be stopped; ending development on uses of the technology that do benefit the end user is not just pointless but actively a bad idea.
There's also a weird conflation that happens between the claim that DoH is "anti-user" and that DoH is "anti-sysadmin". These are two completely different things. If you're a sysadmin who wants to provide a useful DNS service with some additional features on your domain / network, DoH makes it harder for you to do that. I fully agree with this point, and in fact it's a pain point for me because I run Unbound on my router myself! However, this is completely different from the claim that it's "anti-user". Most people do not have friendly local competent admins setting up DNS for them. Those who do are given the choice to opt out of DoH by changing their settings in e.g. Firefox. For other users, DoH is a massive security win. It absolutely makes sense for it to be the default. Anti-admin != anti-user.
The hacker news hysteria over DoH is quite absurd and disappointing. Seeing comments massively exaggerate to downright lie about the situation because they are angry their pihole setup no longer works.
Imo Firefox is representing the users best interests here. The router, and ISP dns servers can not be trusted. The user wants their browsing session to be as private as possible. Cutting out one more source of data leakage is what the user wants.
DoH gives us two things as end users in our homes:
* Privacy from the router and ISP, which is good, and the reason you should use it on your personal computing devices (PC, laptop, phone, RPi, whatever)
* The inability to inspect/redirect/selectively block traffic from anti-user devices we own (Samsung spyware TVs/Chromecasts/Smart ovens/Smart vacuums)
That being said, while I generally trust Cloudflare, it's not the optimal provider for me, and I don't like a random american company being hoisted on me.
Go ahead and give us evidence about how Cloudflare can be trusted. At least we have legally binding contracts with our ISPs.
Also, are you trying to suggest that people who know enough to run Piholes don't know enough to run their own DNS servers (or at least select good ones) and their own routers? That's pretty rich.
> Also, are you trying to suggest that people who know enough to run Piholes don't know enough to run their own DNS servers (or at least select good ones) and their own routers?
If your upstream network is trying to censor or surveil you, you can't run your own DNS server, because it will intercept your queries to the root servers.
This is FUD. This possibility has nothing to do with HTTP vs. [some other DNS-like protocol] sitting on top of an encrypted connection.
This possibility is, however, enabled by having the application package its own DNS resolution. It's unfortunate that more and more software is doing this with no way to opt out (Chromecast and Nintendo Switch are the worst offenders) -- but the way firefox does it, it is opt-out. I think it's a double edged sword; having in-application DNS as an option has an important advantage of subverting malware as well as public wifi networks configured for surveillance. In an ideal world, we don't have to "subvert malware", but we live in a world where a big chunk of users have some sort of malware installed or in their general proximity.
If you want to use DNS over HTTPS as a system-wide daemon, you can use DNSCrypt 2 (https://dnscrypt.info/ ) and disable DoH within Firefox/Chrome.
I have one specific problem but I'm not sure if this is connected. I have a home assistant on a raspberry pi at my parents house. From outside of the network there is no problem, they have a dynamic DNS pointing to their IP address and then port forwarding so that they can access the home assistant UI from the internet.
But they also need to access it from home when they're on the WiFi. Because their router doesn't do this NAT Loopback so that they need to access it via the IP address which is very cumbersome. What I did was that I set up a DNS server which would resolve the dynamic DNS domain to the raspberry pi and pointed the router to use this DNS server. This way they were able to use the same domain in and outside of the network.
I understand that Firefox falls back on the old way of DNS, but I have to assume that Chromecast and Google Assistant will not and therefor it will fail to play local media or show the home assistant UI?
Somehow this fucks up local networks and assumes everything is on the Internet, doesn't it?
In this case using an IPv6 address might work (if your ISPs aren't behind on rolling out IPv6). Alternatively you could tunnel the connection through something intended to break through problematic NAT setups like ngrok (or its alternatives: https://github.com/anderspitman/awesome-tunneling).
I've run a split horizon DNS configuration for years and I've got to say that it caused more problems for me than it solves.
Luckily, you can just turn off DoH if it causes problems for you.
In my experience, the Chromecast and Google Assistant functionality isn't related to your DNS setup. Chromecast should work through broadcast or through an active request from HASS itself, and the Google integration has always gone through the cloud as far as I know.
Perhaps your setup is different than mine, but I don't think these issues are necessarily DNS related, unless Google's servers are getting your local IP when they query for the HASS domain.
Sadly Google Assistant does need to use the DNS setup because I play local media for announcements on it and every time the DNS is broken it stops working and doesn't play any local media anymore. Basically home assistant media player plays a mp3 which is stored on the raspberry pi on the Google Assistant, for example when someone opens the out door it plays a chime on all Google Assistants in the whole house so that my parents know that someone opened the door downstairs. The url will be https://myparentshouse.duckdns.org/local/open-door.mp3 so if the Google Assistant doesn't use the local DNS it can't resolve the domain to the local raspberry pi, and instead resolves it to the public IP address which then without the Loopback NAT doesn't go anywhere.
I understand that I should then instead of using Google Assistant for that to use something else, but I haven't found any free hardware which would have the functionality of good microphones and working speech to text yet.
In that case I'd find a way to put the file universally accessible on the internet somehow (the proxies I mentioned, or IPv6, through HE Tunnelbroker if necessary, or on a random HTTP host you might control?). Debugging split DNS issues can take hours and luckily there are free and cheap tools to avoid this mess! They require some setup, but in my opinion the lack of maintenance they require is much easier to live with than the split-DNS-mess.
I haven't seen much evidence of Google hardware actually using DoH, but they will definitely use 8.8.8.8. If your router has the ability, you could try forcing traffic intended towards 8.8.8.8:53/udp to your router's DNS server.
Organizations that use split-horizon DNS should just add their own domain to network.trr.excluded-domains via enterprise policies rather than disabling DoH completely.
Software that does its own resolution will not run on my network, and we have banned it by policy at work. Of course it becomes another game of whack-a-mole.
My house, my rules; you don't get to subvert my network security and continue to use my network.
That's a perfectly acceptable policy to have, but you'll have to check and monitor that policy like you always have. You can add an A/AAAA record for use-application-dns.net and Firefox won't turn on DoH on your network unless the user overrides it. Chrome's DoH model will use your existing DNS server: if it supports DoH, Chrome switches to DoH, otherwise it'll stick to normal DNS.
Do note that malware and even legitimate software (some Android apps, some Windows applications) have been using HTTP(S) based domain lookups for years, though, years before DoH was even proposed. I've used free HTTP proxies over fifteen years ago to bypass school filters, for one, and that's without any infrastructure of my own!
You'll have to configure an intercepting proxy to exclusively allow traffic through if you want to catch problematic software in the act, and add some pretty sophisticated filtering. With the modern take on inserting your own certificate authority (certificate pinning, unrooted Android, NodeJS, etc. all avoiding your user certificate store) you'll have to go through great lengths to get that working, though.
Truth be told, DNS was never really much of a security measure if you don't have control over what applications do or do not use it.
So far, Firefox is the only browser that has announced support for this. Chrome takes another approach, which is to test the system DNS server for DoH capabilities and to switch to DoH when the resolver supports it. Chrome does have a fallback to Google's DNS if it determines that your DNS server is broken, but you should be able to disable that. That means you can secure your network by picking an existing DNS server that also provides a DoH server and Chrome should pick it up by default!
I believe Microsoft announced a similar approach to Google, but from what I can find you still need to enable DoH manually anyway.
In all cases, the end user can override your domain settings unless your group policies (or similar) lock these settings.
That's the Firefox approach, yes: provide a list of trusted DoH servers and use that to avoid scummy ISP servers that might monitor, intercept, or mess with DNS records.
Chrome has a separate list of DNS servers that it knows can also do DoH. It doesn't change the DNS server, it just changes the mechanism in which the server is queried:
I believe their intent was to auto upgrade existing all DNS servers if they support DoH, but I'm not so sure anymore; perhaps some other product was doing that instead. In theory it shouldn't be too difficult: send a TLS request to dns.server:443, extract the hostname from the TLS handshake, and do a lookup through https://hostname/dns-query (with the IP address hardcoded for the socket to prevent redirect attacks).
Yes, it shouldn't be difficult, but if Chrome isn't doing it, my point is that that would put DNS servers not on that internal list, such as Pi-hole, at a disadvantage.
> I've used free HTTP proxies over fifteen years ago to bypass school filters, for one, and that's without any infrastructure of my own!
I did the same, back in the early-mid 2000s. My favourite were the ones that used ROT13 to get around school filtering of domain names (and banned words in them). Was very cute.
Of course not. That's why you can disable DoH on the software you install, and have the choice (in the EU) to return a product you bought online within 14 days if it doesn't live up to your expectations, or not buy the product at all.
However, it should be clear that we're not ceding control, per se, as we have never had control over these closed source devices in the first place! We should instead be working to gain control over our devices through open source efforts so that we can control what our hardware can and cannot do.
For what it's worth, there is a thread on XDA about customising Chromecast firmware that should allow you to hack the device to disable any unwanted behaviour, but I can't say if that method still works.
Right, and the feature is not designed for you. It's designed for the billions of users who are not on your network, and are sitting in their own home or in a coffee shop where there is no such security policy or skilled network administrator in sight.
Aside: If you are using Firefox in an enterprise environment, you should be locking the settings to begin with. If I remember correctly, the Firefox ESR downloads don't even prompt about enabling DoH.
This is simple: people like you are best served by a policy that manages this kind of policy at the system or network layer. But most people aren't. For most people, the managers of their networks are adversaries. Firefox should, by default, serve most people --- not just nerds like us with strong opinions about the "system resolver".
There is no moral authority to the system resolver. It's a convenience, not a contract.
You should not get to censor people's view of the Internet just because you're providing the connection, just like the gas/electric company doesn't get to decide what you can and can't cook on your stove even though they provide the energy it uses to work.
And if you really only mean your own devices, then enforce your policy on the endpoints instead.
Yes and no. The problem is different - the problem is application vs OS DNS resolvers.
It's not an application job to be a DNS client, this is what actually subverts system administrator policies. Just as if some application has a hardcoded DNS (over UDP) address, but worse because there's encryption and authentication involved, so the system administrator cannot enforce the policy (sans patching the binary or hooking it at runtime).
But if DNS over HTTPS is implemented at the system resolver level there is no issue (and the actual transport doesn't matter).
> DNS over HTTPS is a trojan horse to allow application developers to subvert the system administrator's DNS policy.
No, it's a very important tool to help users bypass censorship and surveillance performed by hostile network operators.
> Specifically, so that companies like Google, Microsoft, Amazon can ensure that you cannot prevent ads being displayed in their little black boxes (hardware or software).
They don't need DoH to do this. They can do this by either hardcoding the IPs of their ad servers, or by serving their ads from the same hosts as the content you want.
> This is dangerous, anti-user, and should be avoided at all costs.
No, it's very pro-user and should be used at all costs.
> DNS over TLS is the correct and appropriate solution here.
No, because that's too easy for the aforementioned hostile network operators to block.
This is a misfeature that needs to go away. Thankfully, Firefox has an override that lets you manually enable DoH even if a hostile network operator configures that.
> but let's be clear here, nobody besides Firefox is going to respect user choice about using DoH.
Correct, but not in the way you meant. Most operating systems and programs will never use DoH even if the user does want it.
I'm running https://crates.io/crates/doh-proxy on my Pihole for DoH access (with an nginx frontend for TLS, though that's not necessary of course). You can just plug it into Firefox and it'll work.
With nginx in front you can put a stream {} block to proxy pi.hole:853/tcp to pi.hole:53 to enable DoT at the same time:
This setup worked great for me with Android, though it doesn't log the requesting device separately anymore (which is why I switched to a DNS server over a WireGuard VPN instead).
Doesn't this only give you DoH and DoT on the local half of the connection? Don't you need to also using cloudflared or unbound to send the remote half over DoH (which is where basically all of the security and privacy benefit comes from) as well?
You're right, but I made the assumption that people want to play around with DNS resolution.
For even better privacy, you'll need something like dnscrypt or enable DoH in your local bind/unbound/knot/powerdns server. Preferably ODoH to have complete privacy, but I don't know how commonly that's implemented yet.
It's not exactly difficult to block 8.8.8.8:443 and 1.1.1.1:443 if ISPs want to block it. There's also no technical reason why DoT should use port 853 even if it's the default; using 443 will work with most clients I've tested, although shitty middleboxes might get confused about the protocol not being HTTPS.
Strange. Those networks must be using a protocol whitelist or something. Luckily, I haven't encountered any networks that will drop 853/tcp outright. All I have is anecdata, but I can't ignore that I haven't seen any reliable statistics about this topic at all. I suspect some businesses or sketchy ISPs will likely block any type of traffic that isn't either DNS or HTTP(S), I haven't seen anyone else use DoT, let alone seen any network care about it.
If I were to encounter such networks regularly (and would not have the option to change network provider), I'd probably switch the DoT port around to 443 or just go directly for DoH.
The idea is that eventually ECH will roll out, and then Google and Cloudflare can start offering this from the same IPs that they do the rest of their services, which there will be way too much collateral damage for the censors to block.
State-level censors will at first ask nicely to block specific entries for their ip ranges; either the provider cooperates (then DoH won't help at all) or not.
If not, they won't have problem blocking entirety of Google or Cloudflare, collateral damage be damned. It would be as much Google's or Cloudflare's problem as it would be user's, so they won't do it. They don't allow domain fronting either.
This is one of my concerns with DoQ (DNS-over-QUIC). Currently DoQ is designated to be on port 853, like DoT, but DoH is great because it's not easily distinguished from other traffic on 443. But, DoQ is a much better protocol so I hope that there is a resolution here, which I'm guessing will be the same as HTTP/3, so we'll see. Maybe in the end it will be the same as DoH.
The DoQ RFC is working on and explicitly setting aside provisions for automatic discovery of alternative ports for the port 443 "blend-in" use case. The designated port is just there for having a standard number to use when admins don't want to have to multiplex everything over UDP 443.
I don't know for sure how the Fx stack presently behaves, but I would expect that eventually it would do DoH/3 if the server provided the appropriate indications (e.g., Alt-Svc).
DNS over HTTPS is useful tool that gives users agency instead of being subjected to the system administrator's DNS policy. It means that in many cases I don't need to use Tor or a VPN to get around network blocks, except on networks with Fortinet. Fortinet even tries to block Tor, but I made a little tool[1] that tunnels BridgeDB requests over docs.google.com so I don't need to worry about that anymore.
As a user it's pretty easy to ignore the DNS settings in DHCP and use whatever you want. An aggressive network admin can identify packets headed to outbound 53 on tcp/udp and block them (or reroute them to the preferred DNS) but they could also block known DoH endpoints. As soon as enterprises realize that DoH is happening, they will definitely do that.
But sometimes you're on a device where you can run binaries but don't have admin access. Firefox lets you use a custom DoH server regardless of the DNS settings set by the admin.
If your admin has set up the necessary policies, you won't be able to configure a custom DoH server in Firefox either! That doesn't work for personal devices, of course, but DoH is explicitly not intended to work around system administrators' configuration.
I'm lucky in that my admins are VERY hands-off (I've had a local admin account for months now that they haven't noticed) so that wasn't an issue. Worst case scenario I could probably build or patch Firefox to ignore Group Policy.
For example, my school laptop had Cisco Umbrella forcing DNS connections to itself, but half the time it never responded. Firefox DoH still worked because it didn't rely on the system DNS setting, which needs admin perms to change. Eventually I fixed the problem entirely by escalating to admin with PrintNightmare and deleting Cisco Umbrella altogether.
If you know how to manage your DNS policy, you know how to turn off DoH or at least how to learn about it. Especially if you're an administrator. I may want to run my own DoH endpoint, which is very much pro-user in that case.
@denkmoon Thank you for speaking up. There are many things about DOH/DOT that many don’t understand. There are protocol issues, privacy issues, security issues. DNS over TLS should be the natural progression.
The reality is that DNS over TLS is a rarity and most users are stuck with poorly operated, unencrypted DNS servers both at work and at home. That's not secure and the lack of privacy is often intentional or even local policy. A lot of operators actually earn some money on the side selling data to advertisers. And they are also more than happy to give local authorities access to that data. Same in companies where your boss likes to know what his minions are looking at in their browsers. These issues are not hypothetical, they are real and the vast majority of users is exposed to this poor status quo.
DNS over HTTPS solves that problem right now by simply bypassing all those poorly configured DNS services. Nothing wrong with that. Why wait for something that might never happen and that is dependent on the cooperation of companies that are clearly not in a hurry to do so when you can go straight to a secure and private by default situation right now? If you have a nice trusted TLS DNS server, use it of course. If not, consider using DOH.
I recently had to figure out why my browser was so slow and then I realized I had not turned DNS over HTTPS on yet (new laptop) and all the DNS requests were taking hundreds of milliseconds. Enough for me to notice and be annoyed by it. That's how bad things are for real users right now. O2's DNS server is not great and they are definitely doing everything they legally can to monetize whatever happens on their servers. They probably also hand over server logs to anyone who asks nicely. So thanks, but no thanks.
So, I turned on DNS over HTTPS and problem solved. And I feel a lot better not broadcasting my browsing behavior to O2 and the various companies they sell my data to. And that's when I'm at home. I also use my laptop and phone in coffee shops, hotels, and via public wifi's, different operators in different countries, companies/customers I visit, etc. DNS over TLS is not an option there. DOH is.
What advantage do you see of DoT over DoH other than that it's easier to block at the network level? If you want to block other people's computers from using DoT or DoH, then you're the adversary that they're meant to protect us from.
>What advantage do you see of DoT over DoH other than that it's easier to block at the network level? If you want to block other people's computers from using DoT or DoH, then you're the adversary that they're meant to protect us from.
Not GP, but I don't want to block other people's computers. I'm only concerned with my computers. And when one of them gets uppity and tries to bypass the policies on my network, it needs to be smacked down. Hard.
As for anyone else's devices? Have at it. Do whatever you want. But my devices on my network will abide by my policies.
That may make you wonder if I'm going to try and steal your DNS requests. But don't worry, I won't invite you into my home.
> That may make you wonder if I'm going to try and steal your DNS requests. But don't worry, I won't invite you into my home.
The problem isn't guests using your house's network. The problem is that if there's a way for you to network-level block DoH at your own house, then nothing is stopping Comcast or China from implementing the same network-level block.
>The problem isn't guests using your house's network. The problem is that if there's a way for you to network-level block DoH at your own house, then nothing is stopping Comcast or China from implementing the same network-level block.
Fair enough.
But I'd posit that you can't prevent a bad actor who controls your network access from doing whatever the hell they please with/on your traffic, whether you use DoH or not[0].
Running a TLS termination proxy would break everything unless they convinced the users to accept their root certificate, so even the most evil ISPs generally don't do that.
That's what I don't want - Firefox offering services.
Once you have a centralized server, with a huge number of minor queries passing through it, the operators get uppity. They start thinking they have editorial authority. Someone will decide that the DNS server should censor something. Child porn is the usual excuse, and then, after a while, you can't see sites that mention Tienanmen Square or Ukraine any more.
I'm quite happy with Sonic's classic DNS server. It just answers DNS queries and forwards requests to the appropriate upstream DNS server as required.