Now I'm confused. Can you elaborate on this a bit? What I meant is that the list of domains to be blocked has to be translated to a list of IPs to be blocked at some point, and that presumably isn't dynamic, because if it is dynamic, why would it ever fail?
It is dynamic, the domains are resolved to IPs on request (or when dnsmasq is idle), but the blocking isn't domain-based, it's IP-based, so if somedomain.google.com and youtu.be share the same IP, both will be bocked.
How are you testing resolution?
Thank you for Simple and now Adblock-Fast!
Similar to @behlers , I found that https://easylist.to/easylist/easylist.txt was also a bit overzealous in blocking domains - google, reddit amongst other possibly legitimate names. I'm pretty certain that the same list didn't block these with Simple Adblock, so if this is by design then fair enough - I'll make do without that one list.
A simple case study is trakt.tv:
Mon Apr 15 20:00:24 2024 daemon.info dnsmasq[1]: 369 x.x.x.x/24211 config api.trakt.tv is NXDOMAIN
# grep trakt dnsmasq.servers
server=/agromastertraktor.com/
server=/invite.traktivity.com/
server=/trakt.tv/
server=/traktinves.com/
server=/traktorist-info.ru/
server=/traktorski-deli.si/
server=/traktrafficflow.com/
server=/traktum.com/
# service adblock-fast check_lists trakt.tv
Found 3 matches for 'trakt.tv' in 'https://easylist.to/easylist/easylist.txt'.
trakt.tv##.playwire
trakt.tv##[data-snigel-id]
trakt.tv##a[class^="hu-ck-s-t-er-"][target="_blank"]
If other domains from the block-list are successfully blocked and this one is not, it's possible that unbound wasn't properly restarted by adblock-fast since the domain was added, but most likely there's a misconfiguration on the router/clients.
There are too many unknowns -- your desktop client may not be using your unbound server for resolution or may have cached the previous non-empty reply, your browser may be using a built-in DoH/DoT proxy, thus bypassing your unbound server. The best way to test would be with nslookup/dig directly from the router, explicitly specifying the IP and port of your unbound server.
In the default config, all the block-lists are disabled and it's up to the user to select the ones they want. I try to include (again, disabled by default) the most popular/active block-lists I'm aware of. Actually, the block-list you're referring to is not a part of the default config at all.
Most likely it was carried over from your simple-adblock config. I have no control over any block-lists or what they block. It's quite possible they started small and then decided to block google and reddit.
While allow-listing is probably the most expensive operation when creating the final block-list and it directly depends on how many domains you want to explicitly allow, you may want to add the domains you absolutely need allowed to a custom allow-list or add them to the allowed domains list of the config like this: https://github.com/stangri/source.openwrt.melmac.net/blob/8a55ec52f22a2136bc35b13813654856f6b888b6/adblock-fast/files/etc/config/adblock-fast#L3
1 Like
Yes - it's a list that I explicitly brought over from SAB during my upgrade to OpenWrt 2023.05.3 yesterday, so I believe that this file was being used without this behaviour somehow (but sure, maybe it was a narrow window of updates that was missed).
I only mentioned this in case the behaviour of ABF has changed from SAB - the thought being that the latter half of the entries were causing these not to be filtered out or something.
Thanks for the allow-list tip. I did start that that route but found that there were way too many and only in this list... so omitting the list is the best bet here imo.
The biggest change was that the block/allow-lists were previously (simple-adblock) stored in the config-file as lists, whereas now (adblock-fast) they are stored as sections, allowing users to enable/disable them, store additional information like list size, allowing the easier check_lists command implementation. The config-file incompatibility is essentially what caused the name change.
The source-lists processing logic had to change a little bit, but not to the point you've mentioned.
1 Like
If other domains from the block-list are successfully blocked and this one is not, it's possible that unbound wasn't properly restarted by adblock-fast since the domain was added, but most likely there's a misconfiguration on the router/clients.
I've tried other domains, but they are also not blocked. I'm not sure if I'm doing it correctly. Just tried adding another one a moment ago. This is what I've done:
- After adding it I save the configuration and start AdBlock-Fast again. Then I restart unbound using: service unbound restart
- Then i do: nslookup domain_to_check 192.168.1.1:53 from openwrt
Unfortunately it still resolves the domain in question.
I did some further investigation @stangri. It seems that the blocking isn't working for the normal block lists neither. I did 5 tests using the same nslookup command as provided in my earlier post. Picked some random domains and none of them were blocked when using nslookup. So either I'm doing it totally wrong, or there's something misconfigured in my setup somehow.
1 Like
More likely there's a bug in adblock-fast, something I may have overlooked either during transition from simple-adblock or some unbound jail/permissions issue.
If you're willing to help troubleshoot it further, I can try posting some builds in my repo when I figure out what may be happening with the unbound integration.
Just to double-check, there's not a dnsmasq instance on port 53, you've disabled dnsmasq and have unbound running on port 53?
There is some problem with the application or firmware-selector.openwrt.org. do not comply with dependencies.
If the application is removed and reinstalled, it does not give any errors. If we collect the entire list of installed packages, we get the following errors.
If you clear the browser cache or run adblock-fast from CLI, you'll get better information.
From your screenshot, I'm not seeing any errors, I see warnings about recommended (not dependent) packages. Installing recommended packages will speed up block-lists processing, however they are not dependencies so that adblock-fast can be installed with the minimal footprint and still work.
Again my bad English))). If you install the program through the same Lucy, then these errors do not exist, everything starts and works. If from a system that works without problems, use a script to collect the entire list of packages installed and running on it and paste this list into the build window of the site firmware-selector.openwrt.org. After building we will receive the following errors (warnings). Then remove and install the same package with dependencies and there will be no errors (warnings) again.
Sure I'll give a hand 
I might have a slight response time every now and then, due to work and kids and stuff, but I'll do my best.
I'm no expert in Linux systems, but I'm trying to learn hehe So I have uninstalled all things related to dnsmasq to the best of my abilities. I think there actually was some lingering configuration from dnsmasq, when I first did the switch and installed Unbound and adblock-fast. I had to change something in a configuration file to have a warning in Unbound go away, but I can't quite recall what it was, besides being a misconfiguration.
I have checked that no running processes named dnsmasq are found:
root@OpenWrt:~# ps w | grep dns
20042 root 1316 S grep dns
and that nothing named dnsmasq is found in init.d
root@OpenWrt:/etc/init.d# ls | grep dns
I looked for installed packages like this also:
opkg list-installed | grep dnsmasq
Then did this to check port 53:
I'm not too deep into Linux yet, so let me know if I've missed anything of if there's something else you want me to try out.
When that happens, please run service adblock-fast dl from CLI/SSH and post any errors/warnings reported in CLI (if any).
I'm pretty sure the final block-list for unbound was missing a crucial line in it, please try adblock-fast 1.1.1-10 from my repo. If you're on snapshots or installed any adblock-fast version which contains -r, you need to download the IPK files from https://dev.melmac.net/repo/ to the /tmp/ on your router, and run: opkg remove luci-app-adblock-fast adblock-fast; rm -rf /tmp/opkg-*; opkg install /tmp/*.ipk to install them.
If the domains are still not blocked by unbound then:
- Please post the output of
ls -la /var/lib/unbound/adblock-fast.conf; head /var/lib/unbound/adblock-fast.confafter adblock-fast had run. - Maybe try adding the following line at the bottom of your
unbound.conffile:
include: /var/lib/unbound/adblock-fast.conf
From my cursory search, I'm not sure if it's needed or not.
Looks like unbound will auto-include “Adblock” files, which may be why you used that naming convention before.
1 Like
I will try it later today hopefully.
Just to be sure exactly what you mean by the above. Are there anything else besides uninstill from Luci that I will need to do, to be sure everything is gone? Like commands or removing stuff manually... I might as well do it the right way, to be completely sure before testing your package, since I'm on 1.1.1-r7
Thanks, seems like it's only done for dibdot's adblock package explicitly, I've sent a PR so it includes the adb_list file created by adblock-fast too: https://github.com/openwrt/packages/pull/23982.
I've updated my earlier post to include command to uninstall existing packages from CLI.
1 Like
Or you can wait until these PRs are merged and build-bots generate new unbound and adblock-fast packages: https://github.com/openwrt/packages/pull/23982 https://github.com/openwrt/packages/pull/23984