General policies
* Should not break useful websites or apps
* Blocks tracking servers
* Blocks advertising servers
* Blocks analytics servers
* Blocks fake websites
* Blocks malware servers
* Blocks webminers
B. "tracking servers" "advertising servers" "analytics servers" "fake websites" "malware servers" "webminers"
If B is larger than A, then a whitelist for A is easier to maintain than a blocklist for B.
Following this logic is not for everybody, much depends on the user's particular web/app usage, but it has worked for me.
It forces an otherwise naive user like me to get to know the "useful websites" and "apps" better, e.g., to be aware of the domains and any third party resources they are using. Some are much more dynamic than others. Thus, some may require constant attention where others may only require an upfront, one-time sunk cost of my time.
Whereas reading through continually updated "blocklists", lists of servers that purportedly have nothing to offer me, is not something I want to be forced to spend time doing. How can we know that the people making the blocklists are not in collusion with the people behind the servers listed in B. At some point, we will be forced to look at what is listed in the blocklists.
I would rather spend that time on a personalised whitelist.
One personal annoyance is sites that use things like CloudFront and regularly change the host without assigning a vanity CNAME so you cannot simply whitelist *.cdn.example.com.
s/web/graphical &/
Additionally having DNS filtering in place will also prevent information leakage in case something goes wrong with one of your browser plugins.
Edit: So that's tunneled DNS.
You could also call it encrypted DNS, I suppose. But then, you could say something similar about VPNs, instead of calling them tunnels.
Hard-coded authenticated DNS would be hard too, but it's at least possible that you could see what resolver it's using.
The bit that will prevent me from pulling this trick in the future is the fact that it’s encrypted.
I was pretty shocked how many widgets and apps ignore the local DNS.
What the network approach doesn't help with is when the ads are served from the same domain as the content. An extension like uBlock Origin solves this problem because it filters the content within the browser.
So I think both approaches are necessary to filter out ads/trackers, and they also complement each other, one at the network level (dnsmasq or Pi-Hole) and the other at the browser/content level (uBlock Origin, PrivacyBadger).
Basically everything except computers. Smart TVs are another one.
- The failure mode is to block rather than allow. Even with a browser with adblocking addons, the addon could accidentally be disabled or uninstalled (by you, by a browser bug, by a browser feature, etc), so you'll start seeing ads. If the DNS server gets disabled you won't be able to resolve anything, let alone see ads.
(I used to do a home-made version of this, but resolving to a local gifserv so that I didn't have to see "page could not load" errors from ad spaces. But recently I got a pfsense router so I've switched to pfblockerng instead.)
Not sure what using dnsmasq would buy me over this setup.
Relevant: Windows will improve user privacy with DNS over HTTPS
Info from notracking: https://github.com/notracking/hosts-blocklists#dns-over-http... Info from Mozilla: https://support.mozilla.org/en-US/kb/configuring-networks-di...
Not sure if Microsoft will do something similar? Else there is still the option to set up your own (local) DOH server and let your router route all DOH traffic to your local DOH instance.
Since pihole and dnsmasq are already requiring disabling DoH, I see DoH as the dead of these kinds of adblock systems.
Why not unbound/bind/etc?
Most edge routers provided by ISP's are running dnsmasq on the underside.
I'd say opposite
It had less examples and docs compare to unbound. At least that was my reason to setup unbound 2 years ago
>Most edge routers provided by ISP's are running dnsmasq on the underside.
True and sad
dnsmasq simply isn’t very good.