And since RethinkDNS' underlying tunnel implementation is in Go, I'm fully expecting wireguard-go to fit in seamlessly.
Same is now available on iOS 14.4(?), via a mobileconfig plist/XML file.
Either use an existing public ad/tracker blocking DNS over (HTTPS, TLS) server, or host your own and enter the hostname there.
If you go down the hosting your own route, you can have a rather neat setup for managing and blocking things via a web browser - it is quite nice to be able to log in and control what's blocked.
Note - if you run an open resolver DNS server on the public internet, usual caveats apply about knowing what you are doing. You don't need to expose port 53 (UDP DNS) if you're using DoT or DoH, which should help.
1. Prevent apps from doing their own DNS. Android's DoT can't do that.
2. Block TCP/UDP connections to IPs per-app.
3. Block all connections when device is locked.
4. Block connections from any app not in the foreground.
5. Forward DNS queries to DNSCrypt v3 endpoints (supports Anonymized Relays) or Tor (via Orbot).
6. Forward all connections over Tor (via Orbot).
NextDNS does a lot more than RethinkDNS, at this point, but no reason why we couldn't implement their feature set. We are a team of three spread thin between the Android app and the stub resolver, but are continuing to make progress. Our focus, unlike NextDNS', is geared more towards anti-censorship.
With RethinkDNS though, right now, you don't need an account and could simply select a set of blocklists and copy the resulting URL to any DoH client . As of today, RethinkDNS, the resolver, is more of a limited BlahDNS / Quad9 replacement than a NextDNS replacement. Limited, because it only supports DNS over HTTPS/[2|3].
That said, we do plan to pick up development pace on the DNS side and FOSS our DNS stub resolver that one could deploy to Cloudflare Workers with one-click .
And may be start catching up with NextDNS on the path it has trail-blazed.
Besides, you could use the RethinkDNS Android app to set NextDNS as your resolver instead of the default preset resolver; if you're on Android 8 or below, or need a firewall and on-device DNS logs.
 Not ready yet, but should be by end of this month: https://github.com/celzero/serverless-dns
P.S. It crashes now and then when I try to enable resolvers.
If I enable them and then exit the software and open it up again, it doesn't save the resolvers I have picked. Is it possible to save the settings?
Strange. I hope you're on the latest version, v053a? I am not able to reproduce it. This is what I did:
1. Setup to use a custom DNS over HTTPS resolver, say, https://trr.dns.nextdns.io/dns-query
2. Force stop the app.
3. Come back to the app and reconnect, and notice it still picks up the resolver from step #1.
I guess you're seeing that in step #3, the app reverts back to "RethinkDNS Basic (default)"?
Can you drop me an email because we have seen reports of DNS flips when using DNSCrypt v3 but not DNS over HTTPS, I am mz at celzero dot com
I'm not sure if we'd ever embed the Tor or I2P library in the app (because we'd need to constantly update it with upstream to ensure we don't slip up on security issues), but never say never.
I have been working on this full-time with a couple other friends since May 2020. We won a grant from Mozilla as part of their FixTheInternet initiative  last year in July, which has meant we could afford to give away the initial versions for free as we continue to work on stability and advanced feature-set that we could charge for.
RethinkDNS is a no-root firewall for Android: It is a mix of both LittleSnitch and Pi-Hole. I believe, it might be the only open source DNSCrypt v3 client for Android.
The website points to bravedns.com because that's the name we launched with. A lot of untangling is required to completely move to rethinkdns.com (for example, older clients still use bravedns.com and do not seem to respect 301/302 redirects), which we intend to do sooner rather than later.
The core firewall is written in Golang, whilst the UI is all Kotlin/Android. We are evaluating a move to Flutter to take this cross-platform, but the immediate focus has been stability and adding support for WireGuard .
Currently, the firewall only tracks TCP/UDP flows. We are in the process of rewiring the firewall's network stack to use gVisor's TCP/IP implementation, and we presume that should improve things considerably.
RethinkDNS, which is a fork of getintra.org, is also an anti-censorship tool. It can, bypass SNI based censorship in most countries like Iran, India, Saudi Arabia (but not all). Eventually, we forsee adding a mesh-VPN like capability to WireGuard (à la tailscale.com) in the app to enable people who "friend eachother" to share each others connections and IPs, similar to now-defunct uProxy , to bypass censorship.
RethinkDNS relies on its namesake stub DoH-only resolver for DNS based content-blocking which is deployed to Cloudflare Workers. This is open source, as well. We are working towards making it one-click deployable so that others may run their own stub resolver; Workers' free-tier supports well over 3 devices worth of DNS queries a month. The stub resolver, as of today, supports blocking over 5M domains from around 171 lists. We plan to support all 2400+ blocklists listed on filterlists.com eventually.
Since the app and the resolver are both super early, I did not expect it to land on HN. It is what it is, but please be kind :)
In the meantime, there's DNS 66, which includes some similar features (minus the app firewall)
This is baseless. There are no proprietary bits. Just because the default build script doesn't take to polyglot codebases well enough does not mean the app contains closed source tech. And I'm in no hurry to fix that myself but welcome code changes from anyone who's willing to put in the work. Here's the issue in case you or anyone reading this is interested: https://github.com/celzero/rethink-app/issues/215
Please don't confidentally pass off judgement on things you may not fully understand. A quick cursory search of the app's GitHub issues would have alleviated your misplaced concerns.
> In the meantime, there's DNS 66, which includes some similar features (minus the app firewall)
DNS66 is insecure. Folks might be better off using DoH/DoT apps like https://nebulo.app/ https://getintra.org/
> It took me a second to grok that this is really mostly just an OSS Android app with some associated DNS servers you can optionally use with it.
Take a second or two more, you've likely missed out on a Littlesnitch-esque firewall which is like 50% of the app; and DNSCrypt v3 support, too; and on-device blocklists; and DNS over Tor support; and support for censorship bypass by protecting against SNI sniffing attacks? It is may be our terrible website design and copywriting skills that did us in. DNS66, as great as it is, doesn't have half the features.
I think my comment must have appeared harsher than I intended, because I'm very excited to learn about this project. When I say "just an android app" that's a massive positive for me, but I understand why it might read otherwise! I had assumed at first blush this was yet another scammy SASS product with a corresponding app, but when I realized it was "just" an open source Android app (and finding the open issue re: working towards F-Droid inclusion) it made me very interested indeed!
I also didn't mean to imply that DNS 66 was anywhere near feature parity with this project, so apologies if that appeared to be the case. That said I have used DNS 66 in the past effectively, despite its limitations. Can you suggest where I can read more about its security deficiencies, or by "insecure" do you just mean to say it is an incomplete solution? (i.e. the lack of protocol support and the reliance on the Android VPN framework?)
My bad. I'm sorry, too. In fact, I may be solely at fault here for over-reacting to your comment. My reaction really stems from an unpleasant r/Android experience where folks just piled up on BraveDNS (as it was called then) with utter non-sense and blatant, misleading lies.
> I had assumed at first blush this was yet another scammy SaaS product with a corresponding app...
This isn't the first time I've heard from folks that the whole thing comes off as scammy / scareware. Is it the website design? The copy? The readme on GitHub? The name of the project?
> Can you suggest where I can read more about its security deficiencies, or by "insecure" do you just mean to say it is an incomplete solution?
DNS66 is insecure in the sense it doesn't do any form of encryption for DNS requests  and, like most other DNS clients, it leaks DNS connections over TCP (only handles UDP) .
I wouldn't call it incomplete, it is likely fully complete in the eyes of the original developers. A DNS client can definitely do more, and that's why RethinkDNS exists in the first place. I used to use Nebulo  which is super light weight, supports DNS over HTTPS/3 (QUIC), and has way more features than any other DNS client I've come across.
> This isn't the first time I've heard from folks that the whole thing comes off as scammy / scareware. Is it the website design? The copy? The readme on GitHub? The name of the project?
This is interesting, it's hard to put my finger on it. There's nothing in particular that I think is "wrong" but there were a few subtle things that might have caused me to bounce were I not already curious:
1) It made the front page of HN (so I'm already primed to expect a SAAS) and it was the landing page (rather than, say, the git repo)
2) The domain name mismatch with the project name - other comments have already mentioned this one - and especially the "Brave" in there (which has an immediate negative association for me)
3) The suggestion of cloud DNS servers and cost model in the main landing page, which made me wonder for a second about the business model and incentives
4) The github link wasn't terribly prominent and the phrase "open source" (while present) doesn't stand out visually (when I see something like this I know to ctrl+f for "github" and "source" so I found both of them without issue, it's that just they weren't immediately apparent).
I know I'm an outlier in many ways, though, so I don't know how far those observations would take you in general. In my case a prominent link to an F-Droid page (or a note by the Play Store badge that F-Droid support is being considered) would have sent a signal I would recognize instantly, for example! Something minor like hosting the APK as a github release and changing the non-Play-Store download link to "download from github" also would have clued me in immediately.
For iOS, there’s Lockdown (lockdownprivacy.com), which is slightly similar to this.
For iOS, my understanding was that Apple already provides a built-in firewall?
Besides, the APIs to track connections/flows per application aren't necessarily available on iOS ?
I used to hack on AOSP for a living, so kind of right at home with Android, right now.
Digging a bit deeper in the developer docs, it looks like it may be possible? https://developer.apple.com/documentation/networkextension/a...
Given that the core firewall is implemented in Go, we should be able to port it to iOS without much worry. But first, must arrange funds to purchase a Mac and an iPhone :)
I don't believe you'd get your PiHole itself to use this service, it's not a public DNS service that you can get your PiHole to point at.
As for NextDNS, are you asking, would you get your PiHole to use your NextDNS as an upstream? You could do that, there isn't a huge advantage to it though... as PiHole is already doing the work for you. Your main motivation to do it anyway would be the consistency factor.
Thats not something pi-hole can do.
Re: Speed graph:
From what I've read, NetGuard's speed graph could be a drain on the battery. Besides would showing connection speed in the app's homescreen suffice?
> I wish I could sandbox specific apps with honeypot contact etc stuff I don't think app needs to have but requires to operate..wtf.
fwiw, we started off by building a userspace application sandbox (many exist today, ParallelSpace, available on the PlayStore, is probably the gold standard), but the bugs and speed was just too dysmal and it seemed it required a long tail of development just to get a v0.1 out of the door. That said, another way to do sandboxing is to use apps like Island and Shelter that abuse Android's "Work Profile" APIs.
So, we switched gears, and instead started focusing on controls for the Network.
Re: Permissions management:
For permissions, specifically, we do have an alpha-implementation that works on AOSP, that auto-grants permissions when the app is in the foreground and auto-revokes it when it is in the background. We are yet to productize it and fix all its rough corners. It isn't priority, but something we eventually want to complete, even if just for AOSP.
Can we set this to use another provider other than 1.1.1.?
Yes, there's an IP firewall too.
Apps can (and do) absolutely use DoH themselves. One way to mitigate is to block DoH IPs (RethinkDNS' on-device network logs are quite comprehensive). This isn't full-proof, and so, a feature we have been contemplating is, firewall would auto-block IPs not resolved by user-set DNS resolver.
Btw, personalDNSfilter can filter millions of entries without problems.
Guess that changed within that month.
NextDNS runs unbound, a recursive-resolver, on rented servers (CoLo not cloud) worldwide, from what I gather.
If I were to deploy a public DNS recursive-resolver globally today it'd probably be on fly.io or on AWS behind its Global Accelerator product.
AFL Firewall can do this atm.
The problem with blocking via VPN is if we close app vpn also closes (instead of running in background as service) which can happen due to clearing all apps.
> The problem with blocking via VPN is if we close app vpn also closes (instead of running in background as service) which can happen due to clearing all apps.
For this problem specifically, you can turn on "Always-on VPN" (to avoid a particular VPN app from being killed or replaced by another VPN app) and "Block connections without VPN" (to avoid traffic from leaking when the VPN app is killed or crashes) against any VPN app from Android's VPN Settings page. RethinkDNS supports both these settings.
> i wish it had added root support which doesn't need vpn to block ip and can use iptables directly.
The only available VPN slot going to a non-VPN app is indeed a deal breaker for many, and so, we plan to add support for WireGuard soon.
Always on VPN doesn't work at least on the Redmi Phone stock rom. When I clear app by closing all apps I get notification "Disconnected from always on VPN" and if i open rethink app it disconnects. So I have to keep it running . I wish there was a way where even if I clear app vpn app runs in background even if I clear all apps..
Strange. We plan to separate UI from the VPN process which would avoid scenarios where clearing up UI process clears up the VPN too: https://github.com/celzero/rethink-app/issues/95
To be clear, you can still clear the activity stack (swipe up dismiss RethinkDNS from Android's Recents screen) which doesn't shutdown VPN; at least not on devices I've tested it on (like the OnePluses and the Oppos). MiUI seems to be aggressive here.
RethinkDNS is both a firewall and a DNS client. Not sure about pdnsf, but RethinkDNS doesn't leak DNS connections over TCP (afaik, Blokada does). Besides, RethinkDNS can also prevent one class of SNI sniffing attacks (typically employed by ISPs as a poor man's firewall to censor websites) which Blokada and PDNSF both don't / can't.
Think of it as a (limited) cross between Little Snitch and Pi-Hole with anti-censorship capabilities.
I would only use it if it is kicked off the Google play store because is against Google's revenue model.
I agree with you though, Google and Apple shouldn't be playing gatekeeper between me and my phone which I bought with my money.