Firefox DNS-over-HTTPS(support.mozilla.org) |
Firefox DNS-over-HTTPS(support.mozilla.org) |
> 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
That depends entirely on your setup.
Notable features DoH gets by being HTTP include:
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.
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.
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.
DoT at least uses a separate port which the network owner can block just like it can block outgoing connections for SMTP (tcp/25).
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.
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.
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.
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?
My house, my rules; you don't get to subvert my network security and continue to use my network.
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).
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.
> 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...
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.
Let Mozilla publish their DNS server addresses then. Let Mozilla (or anyone, it's open source) write a DoH module for pihole.
Problem ~~solved~~ deferred.
[1]: data:text/html,<script>google={visualization:{Query:{setResponse:o=>document.write(atob(o.table.rows.map(e=>e.c[0].v).join("")))}}}</script><script src="https://docs.google.com/spreadsheets/d/1SOK9rEPrVLId1NR4KM-mgDO7tlmRk2K5nNi0tv-9gCY/gviz/tq?tqx=out:json"></script>Seems like in this case it just subjects you to cloudflare's DNS policy (or that of their other "trusted partners")
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.
I strongly feel like Brave would also respect users choices, even though they made some mistakes in the past.
* 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.
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.
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.
You mean a list of the servers they use by default? They already do that; it's currently Cloudflare and Quad9.
> Let Mozilla (or anyone, it's open source) write a DoH module for pihole.
We already have that: https://docs.pi-hole.net/guides/dns/cloudflared/
> Problem ~~solved~~ deferred.
I don't see how.
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:
stream {
server {
listen 853 ssl;
proxy_pass pi.hole:53;
ssl_[...]
}
}
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).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.
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.
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].
[0] cf. Transparent TLS proxies ( https://en.wikipedia.org/wiki/TLS_termination_proxy )
Edit: Changed prose to actually make sense.
That many networks tend to block 853/tcp and not 443/tcp is, literally, a feature of DoT, not a bug.
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.
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.
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.
Out of curiosity, is there any other software that respects this 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.
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.
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.
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.
There is no moral authority to the system resolver. It's a convenience, not a contract.
And if you really only mean your own devices, then enforce your policy on the endpoints instead.
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 correct answer is not to support hardware that does this, in the future.
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.
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.
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.
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.
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.
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.
IMO, the best solution is to replace it with one that does. Split-horizon DNS is a horrible hack that among other things, precludes the use of DNSSEC.
I thought there‘s just a short, hardcoded list of known DoH-supporting DNS IPs.
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:
- https://blog.chromium.org/2020/05/a-safer-and-more-private-b...
- https://blog.chromium.org/2020/09/a-safer-and-more-private-b...
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).
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.
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
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.
Has this ever happened?
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.
[1] See https://en.wikipedia.org/wiki/Lèse-majesté_in_Thailand for more information.
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.
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.
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.
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.
That's what I actually want from Mozilla — offering (but not forcing) privacy-enhancing services, preferably for free.
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.
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.
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.
> 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.
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.
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?
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 ;)
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.
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?
Sorry, but that's not an improvement at all.
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.
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.
In addition, if you configure tailscale on your mobole devices, they can still use your pihole+nextdns/cloudflare even when roaming over 4g.
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.
DoH is great but I feel the pain.
I guess the point is valid for users that don't want / are not allowed / cannot configure the dns server of their operating system.
Don't see how this can work unless Cloudflare/NextDNS is all knowing about the world DNS infrastructure.
I wonder how it does that. Will the browser be making DNS requests for playboy every so often?
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.
that being said, I use this at my work machine so that the local IT agent cannot access the DNS resolver cache
> We began our rollout by default to Russia and Ukraine Firefox desktop users in March 2022.
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.
A toy go program I co-authored can act like the aforementioned "gateway": https://github.com/celzero/midway
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.
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.
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.
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.
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.
I just wish it worked on the whole system
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.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
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.
> people are throwing it away
It is not meant to replace DNS or make it impossible to work.
And by PiHole.
Conspiracy theory I semi-seriously believe: DNS over HTTPS exists so Google Chromecasts can circumvent DNS based adblockers.
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.
> 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.
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 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.
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.
https://en.wikipedia.org/wiki/DNS_over_HTTPS
This is actually considered "a disadvantage" by wikipedia, because of course it means captive portals don't work.
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.
[RFC882] https://www.rfc-editor.org/rfc/rfc882.txt [RFC883] https://www.rfc-editor.org/rfc/rfc883.txt
> 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
What is that?
https://www.congress.gov/bill/117th-congress/senate-bill/353...
I don't know if US ISPs do that, but it can be done.
And yes, I know a cheap router can easily fix this problem. I just haven't had the time..
2) I thought we were just talking about defaults? Firefox DoH lets you choose any server too
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).
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.
I don't want any device circumventing my private DNS; including IoT devices.
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.
I have it installed a few different places on a few networks (Ubiquity, DDWRT, OPNSense, DNSMasq), and it works as expected.
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.
[1] https://community.spiceworks.com/topic/2331415-hosting-isp-d...
[2] https://webmasters.stackexchange.com/questions/120721/how-to...
[3] https://community.akamai.com/customers/s/question/0D50f00005...
Wrong stage of the request. The ISP can block the IP addresses the domain resolves to instead of the domain name itself.
There'd still be fallout if shared hosting is involved, but nowhere near as bad as blocking Cloudflare.
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.
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.
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
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.
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.
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)
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.
From what I remember, the standardization happened after they used it to circumvent ad blockers.
Before this, Chromecasts already hard-coded 8.8.8.8 regardless of what DHCP assigned.
Does that really matter if censoring connections to the DoT server causes your device to silently fall back to insecure DNS?
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.
They intentionally deceive people.
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...
I think of self-hosting DNS on a VM nearby anyway, or maybe multiple ones with randomization. I just haven't gotten around to it yet.
https://arstechnica.com/tech-policy/2019/01/t-mobile-sprint-...
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. :-)
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.
You know you are quite fortunate to be able to say so.
Firefox is a project with global impact. A lot of people around the world can benefit from DoH.
I'm in Canada and the default provider is CIRA. I can also choose to switch to Cloudflare, NextDNS, or add my own.
You can check out the Network Settings at the bottom of the General tab to see what your default is.
And I simply don't trust Cloudflare.
It's just an option. In this case, both selected options are excellent providers that I'm happy to see.
apt install dnsmasq
is my preference.
Even a ten dollar router will let you pick who you trust for DNS.
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.
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.
I'm not going to search for every single article. Or are you seriously suggesting that Reuters is 100% free of propaganda, especially in war times?
The answer your question: "common sense".
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??
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.
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?
“Matthew Prince, Cloudflare’s chief executive. “It’s dangerous for infrastructure companies to be making what are editorial decisions,” he said.”
Not dangerous enough apparently.
I don't care about either side of this argument, but you can't logically turn the question around. The burden of proof is on you, who made the claim.
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.
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.
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.
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.
https://en.wikipedia.org/wiki/Room_641A https://en.wikipedia.org/wiki/Russ_Tice
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.