Hello @dave14305 I took a shot at supporting the allow-listing by explicitly adding the domains to the final dnsmasq.servers file like you suggested in 1.1.2-6 available from dev repo.
It of course took quite a bit longer to implement as I originally hoped, I needed to update both processing of allow/block-lists when downloading, the operation of allow command and even make changes into how the size of the final block-list is calculated, as it would now contain explicitly allowed domains.
Please test 1.1.2-6 as much as you can. I still need to probably add support for allowing domains when using remote dnsmasq config file, but I'd like to have this basic functionality tested.
I was able to install and start some testing during Monday Night Football.
At first glance, Iâm surprised to see that the allowing is only one method or the other (e.g. sed or #), but I was advocating to do both methods at once.
My first test using Hagezi Pro was to allow apple.com. This didnât allow any of the currently blocked Apple sub-domains because the blocked domains are more specific than the new allow entry. You would need to sed out all blocked entries ending in apple.com and then add the new entry server=/apple.com/#. The sed is technically enough for this particular scenario (allowing a higher-level domain of one or more blocked domains), but since you wonât know in advance if itâs a partial match, exact match or no match, you should execute both methods.
The next test was to whitelist a random doubleclick sub-domain 9120651.fls.doubleclick.net since fls.doubleclick.net is in the block list. This works as expected. 9120651 resolves properly, and any other subdomain like 9121695.fls.doubleclick.net continues to be blocked.
Allowing an exact match of blocked domain like browser-intake-datadoghq.com works as expected.
@dave14305 I thought it would be a significant speed improvement if I didn't need to purge the final block-list from allowed sites, but I see your point. So 1.1.2-7 available from OpenWrt snapshots repo and from my private repo has the proper processing as you suggested.
I have previously ignored the news about the per-instance conf-dir support for dnsmasq (applicable for dnsmasq.conf, dnsmasq.ipset and dnsmasq.nftset configurations only), but was reminded about it with the recent drama with switching default values for per-instance conf-dir.
The adblock-fast 1.1.2-10 (and please update the luci app to the same version), has support with configurable per-instance conf-dir for dnsmasq. I've quickly tested with all 3 options affected (and dnsmasq.servers which is not affected) and it seemed to work for me.
If you use adblock-fast with either dnsmasq.conf, dnsmasq.ipset or dnsmasq.nftset options for resolver, especially if you have multiple dnsmasq instances, please install 1.1.2-10 and test.
Pending any reported bugs, I'll be creating PRs for OpenWrt packages both snapshots and 23.05 repos before the end of the week.
I observed some âUnknown warningâ lines in LuCI after installing a new build from sources. I neglected to install the recommended packages (gawk, grep, sed, coreutils-sort) and get the warning as expected.
Service Warnings Some recommended packages are missing
Unknown warning
Unknown warning
Unknown warning
I thought the extra warnings odd and checked the json response:
The additional packages each create a separate id, and so the id doesnât match a pre-defined warning text. Not a showstopper, but perhaps the json needs tweaking if multiple packages are missing?
This is a build off snapshot (actually the pesa1234 build for MT6000, but same official âpackagesâ repo for Adblock-fast).
Did you happen to be in the config directory when you ran the stop?
I wanted to test this, so I copied my config file to ~/adblock-fast and then ran the stop and afterwards, the config file was still in /etc/config, but the backup in my current directory had disappeared.
Thanks @anomeome for posting and @dave14305 for investigating, it did sound like a bigger issue than just apk compatibility and I'll take @dave14305 findings to fix this, hopefully over the weekend!
I'm currently trying to setup adblock-fast on a second dnsmasq instance that is only used by specific devices.
I also have stubby running which uses 127.0.01#5453 (+ipv6) on the main instance.
I don't get what im doing wrong, I also don't get how to configure the ports correctly. The second dnsmasq instance (where adblock-fast is pointing) needs a different dns port because you can't run multiple thongs on port 53. What port do I pick? How is this related to the force dns port option? Do I need to setup some firewall rules?
Custom dns on the LAN interface is clear, custom dns on WAN points to cloudflare.
The way hijacking is implemented in adblock-fast, it maps the hijacked port from the requests to an open port on the router or drops the requests if this port is not open on the router. In your case, the clients are likely to send requests to hard-coded DNS servers still on port 53, whereas the target dnsmasq instance is not going to be running on port 53, so yes, you may have to set up the hijack firewall rules manually. Maybe it would be easier to configure adblock-fast on the primary (port 53) dnsmasq instance and set your LAN clients where you don't need adblocking to use an alternative instance.
