Implement "block domain" action in the DNS logs view

[ignoramous]

This is very pi-hole-esque feature request. May or may not be in-line with PlayStore's terms of use.

Basically, add a block / unblock action next to every DNS log entry; and build a local blocklist that way. This feature might be confusing, since a user can't really "unblock" a domain blocked by AdGuard DNS, for example.

1. 279

2. 208

[ignoramous]

A user says,

I am using just some domains with wildcard for my personal preference. Here is it.

*googl*
*facebook*
*fbcdn* 
*fbsbx*
*gstatic*
*gvt*
*olx*
*netflix*
*netclix*
*truecaller*
*telemetry*
*wzrkt*
*youtube*
*zune*
*metrix*
*metric*
*banner*
*coin*
*admob*
*yahoo*
*yimg*
*mozilla*
*mozaws*
*firefox*
*whatsapp*
*android*
*pangle*
*byteoversea*
*ibytedtos*
*firebase*
*ocsp*
*opera*
*appspot*
*.astrocamp.*
*.astrosage.*

[BayLee4]

Hello @ignoramous 👋 Is there any update on the issue? It looks like #380 implementing the whitelist/blacklist options has stalled.

I'm quite hyped up for this feature, I really wish we see it soon as I couldn't bear Blokada and its unintended disconnections any longer (this feature is the only thing that refrains the switch, #355 would be more the icing on the cake than the cake itself).

Happy holidays to you and the team, BayLee4

[ignoramous]

Hi again: It has taken absurdly longer than it should have...

The progress on the UI side of things (#380) is going on full swing. The network engine related changes are the ones pending to complete domain allow/deny impl. I was the one working on it, but had to shift focus to sort out serverless-dns deploys for DoT. As for app's network engine changes, I expect things to reach some form of completion in the next 2 weeks, with a further 2 weeks to weed out the bugs, if any.

[ignoramous]

The previous impl was abandoned for it got too ambitious... we are doing a retake that's been progressing at a pretty good pace. Let's see... how long...

[woj-tek]

I was just searching for a whitelist - there is a mention of "Allow or deny individual domains" with subtext "comming soon". Unfortunatelly there is one website (rp.pl, one of the best Polish newspapers) that relies on "login.greminimedia.pl" which for some absurd reason is included in a lot of lists that RethingDNS recommends (in section "porn", which is bizzare) which virtually blocks access to the website for paying subscribers... I was pondering making PR to remove them but there are almost dozens of lists so I tried removing mostly all of them but still some remained... so in the end I simply disable RDNS when I want to read rp.pl on my mobile... Having whitelist would be wonderful here.

Btw. having a page "blocked by RethinkDNS" would help a lot as for a moment I thought the issue is caused by network issues and only later on relised it's due to blocking.

[ignoramous]

Btw. having a page "blocked by RethinkDNS" would help a lot as for a moment I thought the issue is caused by network issues and only later on relised it's due to blocking.

This involves asking users to install a self-signed root TLS certificate vended by us. This is needless as it completely breaks the Web PKI trust model. I know NextDNS does this (because their paying customers must have asked for it, I presume). I remain unconvinced of its actual value given the risks.

Having whitelist would be wonderful here.

The whitelist / allowlist code has been pretty merged into the app since v053i (July 2022), but we don't show the UI because of the way it breaks other features. Right now, the only developer on the app is busy with another project, but once he's available again (in a week or so), allowlists are going to be our sole focus. Hopefully, this lands in the coming month or two.

I know we have been saying we'd impl this feature but for over a year we haven't, though in our defence, not only has it been a struggle to impl it, we have instead gone on and impl a lot of other firewall features that we really started the Rethink DNS + Firewall project for.

In short, Rethink was never meant to be a full-fleged DNS-based content-blocker, and the code wasn't really setup to handle custom whitelists / allowlists: The app runs the same code (ported to Golang) that we run on our resolvers; and our resolvers (written in JavaScript) were never meant to have allowlists / whitelists.

[ignoramous]

@woj-tek btw, neither rp.pl nor login.greminimedia.pl are blocked by any lists: https://rethinkdns.com/search?q=rp.pl%2Blogin.greminimedia.pl (the latest ones were updated on 8 Dec).

Can you check if you're on the latest blocklist version? For RDNS+, tap on the green-coloured chip at the top right-hand corner of the Configure -> RethinkDNS UI to update. For on-device blocklists, go to Configure -> On-device blocklists -> Check for updates and follow instructions from there.

[woj-tek]

I'm sorry, I was typing from memory and make a typo: https://rethinkdns.com/search?q=login.gremimedia.pl I don't know why RDNS marks it as "porn (+2)" though

[ignoramous]

I don't know why RDNS marks it as "porn (+2)" though

Update your RDNS+ metadata:

Tap on the green-coloured chip at the top right-hand corner of the Configure -> RethinkDNS UI

Screenshot of the Configure -> RethinkDNS UI.

Notice the green-coloured chip "check for update" a the top right-hand corner? Tap on that. 

Btw, in case you didn't know, you can tap on the "Porn +2" chip and it should show you th correct lists blocking the domain (if the metadata is up-to-date).

[woj-tek]

It's up to date. I know that I can tap on the "Porn +2" chip to get the details but there is a weird issue - I disabled almost all lists (left only 2 of them - confg screen shows "2 blocklist in use") but the DNS log still shows "Porn +2" and lists 7 lists.

I mentioned "Porn +2" also because the chip name seemed kinda weird...

EDIT: OK, how can I only use on-device lists? I selected RDNS Default (only 1 block list) and disabled any on-device list and now the login.gremimedia.pl is still blocked but it doesn't even get listed in the logs...

[ignoramous]

I mentioned "Porn +2" also because the chip name seemed kinda weird...

Would you please post a screenshot of the dialog that comes up when you tap on "Porn +2"?

...disabled any on-device list and now the login.gremimedia.pl is still blocked but it doesn't even get listed in the logs...

My guess is, the (blocked) DNS answer must be cached. Try after STOP -> START Rethink app once (that's one way to flush the Android's DNS cache).

EDIT: OK, how can I only use on-device lists?

You can connect to System DNS or any other DoH endpoint in Other DNS from the Configure screen.

You can also remove all lists in RDNS+ (and keep it at zero lists).

I disabled almost all lists (left only 2 of them - confg screen shows "2 blocklist in use")

This is a bug where dead lists with 0 entries are never unselected (because the code assumes that these could not have been 'selected' in the first place): https://github.com/celzero/rethink-app/issues/710 Will fix it in the upcoming release... (:

[woj-tek]

Would you please post a screenshot of the dialog that comes up when you tap on "Porn +2"?

I think it was caused by first item of the list being in "Porn" category and then there were two more categories. Though, can't replicate it now as I was playing with RDNS and can't get it to previous state - stop/start helped apply correct list set as you mentioned in your second comment. With that I was able to eliminate problematic lists and now it works as expected.

You can connect to System DNS or any other DoH endpoint in Other DNS from the Configure screen. You can also remove all lists in RDNS+ (and keep it at zero lists).

But with SystemDNS I don't have "on device filtering"? Or at least it wasn't working when I configured it that way.

[ignoramous]

But with SystemDNS I don't have "on device filtering"?

From v053l (released first week Dec 2022), On-device filtering, if enabled, should work with all DNS, DoH, DNSCrypt, and DNS Proxy.

With that I was able to eliminate problematic lists and now it works as expected.

Glad you were able to sort it out (:

[ignoramous]

Impl after a treacherous refactor of multiple codebases. Will land in v054 (final tests going on right now, but there's at least one show stopper bug, so v054 might either be released tomorrow, or next week, or ...):

screenshot

developer build: 

[ignoramous]

v054 is a go.