@antonk I am aware, but if you take a look at Pi-Hole and AdGuard Home, both of them provide DNS over TLS aswell (both adblocking and DNS over TLS working through the same DNS forwarder).
@Ree9 How well supported is DNS over HTTPS these days? I remember it being quite niche a few years ago.
I've an old router (which isn't being used anymore) with stubby installed, but ended up disabling the service after a while due to the lack of DNS over TLS support in some DNS servers that I was using at the time.
Figured I would ask first if a separate application (like stubby) was required or if support was already baked into the project.
If youāre using an older router then I think you may as well forget those alternatives since the memory consumption will surely be unbearable for reasonably sized blocklists. dnsmasq is ubiquitous and highly optimised, and there is no reason why stubby shouldnāt work for any upstream resolver. DNS over TLS is a protocol. Stubby is an advanced implementation and very widely used.
My gov has been doing this for years already. They are only enforcing the ISP providers to block certain sites with the ISP's own DNS lookup. So easily circumvented using a different DNS resolver(s). But 80% of the population wouldn't even know how to do this, and many of the ISP modem/routers have this locked down, so it is somewhat effective against the general population.
Also I use stubby & adblock-lean, works perfectly.
Tragic that in the West censorship is becoming increasingly palatable. Itās not even so inconceivable that in the not too distant future UK citizens will need to use a VPN to access X. OpenWrt and Wireguard to the rescue!
From what I know so far it's aimed at blocking mostly illegal content, such as illegal porn (as apposed to legal porn), pirate sites, some malware sites etc.
At least there is no punishment for working around it (working around it is different than using those sites). But it's not just west doing this, and nowhere near the level of some authoritarian gov'ts.
Yikes yes definitely good to block that stuff. Iām a big fan of the Cloudflare family filter. That seems to block the vast majority of the soul-destroying content out there.
You misunderstood my post. I tried network-wide DNS over TLS years ago on an old router (this router is no longer in use), no adblocking, just stubby. However at the time, the DNS service I was using (I believe it was dns.watch) did not offer DNS over TLS, so I ended up just disabling stubby and forgetting about it over time.
Brazil has just blocked Twitter/X over X's refusal to censor opposing political accounts, which is odd, since X is still very censorship heavy.
While I don't use or care about Musk's walled garden (after they killed Nitter, it's nearly impossible for you to view content without an account), I found it very disturbing how quick and without any resistance large ISPs were to block it (the block is unconstitutional).
For multiple reasons, I can't deploy a network-wide VPN and I also don't trust VPN services with my data, just like I don't trust my ISP. The Tor network is a good solution for privacy, but unfortunately it's slow and its exit nodes tend to get blocked often (or forwarded to infinitely looped captcha hell).
So, my compromise is to disable my ISP ability to snoop my network's name resolutions. If they are so eager to follow an unconstitutional demand and block a huge website, they would've no problem turning on its customers for any arbitrarily enforced wrong-thinking.
DNS over TLS, combined with the majority of my network traffic being HTTPS, makes it harder, albeit not impossible, for them to spy on my network.
Since other applications that do adblocking also support DNS over TLS, I wanted to make sure whether this one also supported it out of the box or not.
Today i ran a service adblock-lean update and afterwards I ran service adblock-lean restart
Summary
Sun Sep 1 11:06:45 2024 user.info adblock-lean: Restarting adblock-lean.
Sun Sep 1 11:06:45 2024 user.info adblock-lean: Stopping adblock-lean.
Sun Sep 1 11:06:45 2024 user.info adblock-lean: Removing any adblock-lean blocklist files in /tmp/dnsmasq.d/ and restarting dnsmasq.
Sun Sep 1 11:06:51 2024 user.info adblock-lean: Stopped adblock-lean.
Sun Sep 1 11:06:52 2024 user.info adblock-lean: Started adblock-lean.
Sun Sep 1 11:06:52 2024 user.info adblock-lean: gawk detected so using gawk for fast (sub)domain match removal.
Sun Sep 1 11:06:52 2024 user.info adblock-lean: coreutils-sort detected so sort will be fast.
Sun Sep 1 11:06:52 2024 user.info adblock-lean: No existing compressed or uncompressed blocklist identified.
Sun Sep 1 11:06:52 2024 user.info adblock-lean: No local allowlist identified.
Sun Sep 1 11:06:52 2024 user.info adblock-lean: Not using any allowlist for blocklist processing.
Sun Sep 1 11:06:52 2024 user.info adblock-lean: No local blocklist identified.
Sun Sep 1 11:06:52 2024 user.info adblock-lean: Starting blocklist part(s) download.
Sun Sep 1 11:06:52 2024 user.info adblock-lean: Downloading, checking and sanitizing blocklist part from: https://raw.githubusercontent.com/hagezi/dns-blocklists/main/dnsmasq/pro.txt.
Sun Sep 1 11:06:54 2024 user.info adblock-lean: Successfully processed downloaded blocklist part (source file size: 4.29 MiB, sanitized line count: 162,862).
Sun Sep 1 11:06:54 2024 user.info adblock-lean: Downloading, checking and sanitizing blocklist part from: https://raw.githubusercontent.com/hagezi/dns-blocklists/main/dnsmasq/tif.medium.txt.
Sun Sep 1 11:06:55 2024 user.info adblock-lean: Successfully processed downloaded blocklist part (source file size: 3.78 MiB, sanitized line count: 155,032).
Sun Sep 1 11:06:55 2024 user.info adblock-lean: Successfully generated preprocessed blocklist file with 317,894 lines.
Sun Sep 1 11:06:55 2024 user.info adblock-lean: Sorting and merging the blocklist parts into a single blocklist file.
Sun Sep 1 11:06:57 2024 user.info adblock-lean: Processed blocklist uncompressed file size: 7.71 MiB.
Sun Sep 1 11:06:57 2024 user.info adblock-lean: New blocklist file check passed.
Sun Sep 1 11:06:57 2024 user.info adblock-lean: Successfully imported new compressed blocklist file for use by dnsmasq with size: 2.02 MiB.
Sun Sep 1 11:06:57 2024 user.info adblock-lean: Restarting dnsmasq.
Sun Sep 1 11:07:06 2024 user.info adblock-lean: Restart of dnsmasq completed.
Sun Sep 1 11:07:06 2024 user.info adblock-lean: Processing time for blocklist generation and import: 0m:14s.
Sun Sep 1 11:07:06 2024 user.info adblock-lean: Checking active blocklist.
Sun Sep 1 11:07:06 2024 user.info adblock-lean: Active blocklist check passed with new blocklist file.
Sun Sep 1 11:07:06 2024 user.info adblock-lean: New blocklist installed with good line count: 303,096.
Sun Sep 1 11:07:07 2024 user.info adblock-lean: The locally installed adblock-lean is the latest version.
I canāt say I have so much knowledge of the alternatives but donāt they just use dnsmasq as a backend anyway? As far as Iām aware, they entail a significantly greater processor and memory footprint.
I am not discussing pros and cons, just that the ones I've mentioned support DNS over TLS either out of the box or with some extra minimal setup.
My original question was about whether this project required an extra application, like stubby, or if a modified dnsmasq (or additional middle man software) was shipped with it in order to support DNS over TLS.
I can't run demanding adblocking software on my cheap single CPU router running at 775 mhz (which is why I am discussing this here). My goal is DNS over TLS, but figured I could run adblocking too, as the adblocking solutions that I've mentioned support DNS over TLS effortlessly.
But you can run adblock-lean on such hardware, right? The whole point of adblock-lean is reduced processor and memory footprint, and to facilitate blocking adverts on weaker hardware.
So you have a choice between software that you canāt run that integrates the functionality in sense of providing a LuCi interface for the same or software you can run that does not provide a LuCi interface (at least not one that can be leveraged to configure DNS over TLS in the same application).
You are. Network-wide adblocking is just a bonus for me, since I generally leave that for the clients in the network to implement their own adblocking.
I've tried to explain this in the previous posts, but apparently I've failed to do so.
My goal is DNS over TLS, but some solutions that provide it also provide adblocking without additional software (AdGuard Home for example).
I was unfamiliar with this project (adblock-lean), so I asked if DNS over TLS was also baked into the project, because that's my main goal. A quick look at the repository and the replies above, showed me that it doesn't have DNS over TLS by itself, requiring third party software, such as stubby (the question was answered here).
Since AdGuard Home is too big for my main router (which also lacks USB ports) and I obviously can't run Pi-Hole on it, I am just wondering whether I should bother with network-wide adblocking or not and just use stubby, as that's my main goal.
Adblocking was convenient because the same software that was providing DNS over TLS was also providing adblocking, it has nothing to do with LuCI whatsoever.
I can't advise you on this, but you could just try it and see if you like it. It's not complicated to set up. I'm pretty sure that adblock-lean is the fastest and most memory-efficient dns-based adblocking solution for OpenWrt. We are currently working on a new version which will be yet faster and use much less memory to process the lists from the 2nd run on. Should be probably released in the next few days.
For multiple reasons, I can't deploy a network-wide VPN and I also don't trust VPN services with my data, just like I don't trust my ISP. The Tor network is a good solution for privacy, but unfortunately it's slow and its exit nodes tend to get blocked often (or forwarded to infinitely looped captcha hell).
So, my compromise is to disable my ISP ability to snoop my network's name resolutions. If they are so eager to follow an unconstitutional demand and block a huge website, they would've no problem turning on its customers for any arbitrarily enforced wrong-thinking.
DNS over TLS, combined with the majority of my network traffic being HTTPS, makes it harder, albeit not impossible, for them to spy on my network.
The addresses resolved from x.com are currently black holed by my ISP, but see my quote above for the reason to enforce DNS over TLS for all name resolutions.
How well supported is DNS over HTTPS these days? I remember it being quite niche a few years ago.
DNS over TLS is just as safe as DNS over HTTPS, but I've found more DNS servers supporting DNS over TLS than DNS over HTTPS.
I don't necessarily care if my ISP can see inbound and outbound traffic through the DNS port; as long as the encryption holds and they don't start dropping/traffic shaping these packets, the only thing that they will be aware of is my network doing name resolutions, which any network connected to the internet does.
Well the logic is a little hard for me to follow, but no matter. Here is how I see it. You indicate that you canāt run those other advert blocking utilities on your router, so we can forget about those.
Stubby is a great choice for an efficient DNS over TLS implementation.
It is implemented as a service script without dependencies. It leaves no trace (save I think for a temporary directory in /tmp that would get removed on reboot) if the service is uninstalled. Isnāt that right @antonk?
And given its low processing and memory footprint, it may well work just fine (you may just want to use the smaller blocklists for weaker routers as outlined in the README). Try it!
If you are dissatisfied with adblock-lean you can just remove it and keep using stubby and client-based advert removal. In this case, weād love to receive your feedback.
Actually I have a question about this. Has there been a comparison of the relative performance between the various DoT and DoH implementations in OpenWrt?
Stubby has always worked well for me, but Iād switch over to one of the DoH implementations if one of them is faster.
Please donāt worry too much about straying a little off topic at least from my perspective for whatever thatās worth. I always quite like excursions!
Indeed. The only thing besides the script in /etc/init.d is the config file which is currently in /root/ but it's going to move to /etc/adblock-lean/ (maybe with the upcoming update). When upgrading from one version to another, if automatic config changes are made then the old copy of the config file is saved in /tmp/. But that's it. That is unless you added local allowlist/blocklist or a custom script which adblock-lean is able to run to report success or failure to your email etc.
Hi guys! Amazing work as always. Just a quick question: In the newer versions, it seems that the rogue element detection now skips the file entirely if a rogue element was found within. I seem to remember that only the element itself was removed. Am I misunderstanding something, and why has this choice been made?
Hey, skipping the whole file containing rogue element has always been the approach. Adblock-lean never excluded just the single line. The logic is that if a blocklist contains a rogue entry, then assume that whole file is potentially a problem.
But do you have an example of what is happening for you?
Indeed - we never just removed a rogue element. I think the thinking was that rogue elements should really not crop up by definition and if they did one should be investigating!
Always open for discussion. If there are good reasons to offer the option to simply excise them we can easily implement this. But at least in my mind we shouldnāt just paper over such rogue elements because rogue elements can include nefarious tricks like redirecting a domain to an IP. So we should treat these seriously.