Pi-Hole – A black hole for Internet advertisements
github.com
github.com
What am I worried about is DNS based black-holing is trivial to workaround against (as an ad-provider, one could simply force use a custom DNS client and pin to a DNS resolver of choice) [2][3][4]. What's next for pi-hole and solutions like AdGuard DNS short of re-writing packets going through UDP/53? Not sure how one would intercept the DoTLS / DoHTTPS connections, to rewrite those.
I'd like to hear if anyone has some thoughts on this, or if this has been discussed elsewhere.
[0] https://simplednscrypt.org/
[1] https://news.ycombinator.com/item?id=18788410
[2] https://news.ycombinator.com/item?id=19170671
[3] https://news.ycombinator.com/item?id=19106023
[4] Firefox 64 for PC, by default, was configured to ignore OS/Network Interface provided DNS resolver and used CloudFlare's over HTTPS.
https://uk.pi-supply.com/products/pi-hole-kit-network-wide-a...
Basically.
Just got a RPi3B+ with all of that from Microcenter for 53 dollars
Regardless name resolution based ad blocking is relatively futile against even naive workarounds. For instance what is to stop someone from using a custom DoHTTPS format on any webpage to resolve the name directly in browser? What's to prevent them from obfuscating it in a way your MITM couldn't realistically detect?
In the end ad blocking is best done directly on the client through something like uBlock Origin. Not only does this allow you to create a network request block list (now with the added capability of reading/filtering on the whole URI) but it also allows for style based blocks where the ad content could even be blocked if it comes from the same server and resources serving the actual page.
Of course, a pihole will not be able to block someone who goes to the length of developing and using a custom DNS-over-TLS or DNS-over-HTTPS webpage.
Similarly uBlock origin is not available for anything else except browsers. There is nothing preventing native apps from using or pinning different nameservers. On a scale of hardness, using or pinning a specific DNS server is easy and is known to be used in wild. Custom DoT or DoH is still rare but I am aware that there will be a time when a significant chunk of internet will use it.
Name-resolution based ad-blocking is not futile yet. My pihole has alone blocked 5k+ queries in the past 24h.
That sounds horrifying.
- Removes all DNS leak privacy issues, for all Firefox users, automatically
- Removes all possibility for a MitM to view or corrupt DNS queries or responses, for all Firefox users, automatically
And Cloudflare claims to delete all DNS-related logs of Firefox users within 24 hours: https://developers.cloudflare.com/1.1.1.1/commitment-to-priv...
Even if you distrust Cloudflare or think they're not secure against breaches, it's still a massive security and privacy upgrade over using your ISP's DNS servers, which will pretty much always leak sensitive information about your connection (potentially leading to deanonymization while using an anonymizing service) and send/receive everything in unauthenticated plaintext.
And in addition, your ISP likely is less trustworthy and less secure against breaches (even if you aren't using Comcast, Verizon, or AT&T) than Cloudflare. But again, even if you don't trust them, this would still be the best move for security.
Plus it's a big latency decrease and performance boost for most or all users.
Even in Europe big telcos like Telenor have adtech holdings.
It doesn’t mean you can’t trust your ISP but certainly there are red flags.
But also somewhat common[1] is the router handing out itself as the DNS server, which is really important if you want local domains to resolve correctly. Firefox skipping straight to 1.1.1.1 means it won't be able to resolve my local network servers via name, which is stupid.
1: Not common in home use sure, but definitely common in anything run by an IT staff.
My ISP is trustworthy and is in my own city/country. Today I've discovered that all my DNS queries now go to a foreign company that I know nothing about, and did not consent to communicate with.
I'm all for encrypted DNS, but I'm not for my DNS server choice being silently overridden.
Encrypted DNS and devices like the Pi-hole provide end users a means of bypassing this behavior by avoiding ISP DNS servers entirely so even where you're trying to go isn't known by them.
Another big concern is privacy from the other side: if you're using Tor or an anonymizing VPN while visiting a website looking to deanonymize users, and the website owners see a DNS query to their nameserver from a Comcast DNS server somewhere in a midwestern state timed perfectly before your HTTP request coming from a Tor exit node or anonymizing VPN, they can potentially infer your broad location and ISP, and potentially narrow your identity down from there (especially if you ever visited that site, or an affiliated site or site that shares data with them, in the past without using an anonymizer), negating the purpose of the anonymizer.
If all they see is a query from 1.1.1.1 or 8.8.8.8, you could be anywhere in the world, using any ISP.
And your ISP can do this in an even more precise way. Customer makes DNS query for siteispsdontlike.com and then immediately sends a lot of traffic to a server registered to an anonymizing VPN company. That tells the ISP "this customer is visiting this 'suspicious' website, and also covering it up by using this specific anonymizer".
We basically seem to both agree with the original GP. Things just got a little confused.
Disclosure: I work at Mozilla but not on this.
Putting a DNS client in Chrome (I think they removed it but who knows), or Chromecast, or whatever is "evolutionary pressure".
It forces users to evolve the solution to work around it. This is good.
If users are forced to learn to use an RPi for DNS (and we can see they are doing that with Pi-Hole), and eventually another pocket-sized computer with open-source software for routing, that benefits the community of users who want to avoid ads.
If avoiding ads is the goal, then using a pocket-sized computer with a user-installed OS is better than a solution marketed by a commercial third-party, as almost always those third parties rely partially/wholly/directly/indirectly on the ad business.
I don't understand why he says you have to route and answer 8.8.8.8. You really don't.
If his point is you can't override the built in DNS without some sort of FW hackery though, then yea his point stands.
Seems like blocking Firefox and Chrome from usurping your DNS choices is going to be much harder going forward. :(
I think the main reason the browsers have added support is so they can get the data they need to make encrypted SNI work. They’re going to have to get operating system APIs to be able to do this from the OS’s resolver or else it will screw all sorts of things up.
So I guess in theory you can block that port outbound to all hosts to handle TLS's use case.
HTTPS is tougher, but just block all traffic to those hostnames with a DNS blacklist.
DoH does, in fact, use 443/TCP, just like regular HTTPS traffic.
How does Pi-hole mitigate this issue for non-expert users? My main concern is that if I set this up at home, my wife will get annoyed when her web pages don't work and won't have the patience to learn how to add to the whitelist.
If you're enabling ad filtering on the DNS level on your router, its more along the lines of forced ad filtering on your entire network, so you're kind of sacrificing user configurability for global ad filtering on your network.
Personally, I've only had the experience of a broken webpage once in two and a half years of using it.
Is there a reason DNS-based filtering is much better than normal ad-blocking in this respect?
Very occasionaly I might come across something not working. I could go to the pi-hole interface and whitelist, but I find it easier and so infrequent that I usually just turn off WiFi for a minute to load the page over cellular.
Granted, none of this answers your question directly, but a manual Network Location switch from System Preferences is a somewhat simple change that's a little less friction than a whitelist. The auto changer should switch it back next time your wife's computer reconnects to the network in case she forgets.
I haven't had any issues come from me or anyone in my family using it thus far. Although, there's an active discussion which that whitelist pulls mostly from here: https://discourse.pi-hole.net/t/commonly-whitelisted-domains...
I've unexpectedly nice thing was the Roku screensaver went back to a simple bouncing logo instead of the ad-filled scrolling billboard thing.
The game's name is Covet Fashion. They have a huge following in Facebook. The main theme of the game is to dress up models and others vote on it. Whoever gets the "top look" wins (winner gets virtual currency to buy more dress I think). I think they even form teams through Facebook. Sometimes people get kicked out for not helping the team and so on, so I guess there is some drama like reality TV.
It's more trusted nowadays and very easy to switch to.
So pi-hole-as-a-service doesn't make too much sense.
My setup has been running for over a year and it has completely transformed the Internet for me.
* https://discourse.pi-hole.net/t/commonly-whitelisted-domains...
* https://github.com/anudeepND/whitelist
I have ~2.2M domains blocked. There's just no way that I wouldn't have false positives in that big of a list.
However, as it's been said, you might want to easily whitelist some domains.
https://github.com/AdguardTeam/AdGuardHome
Pi-hole isn't difficult to setup but AdGuard Home is much easier. Just download the binary and run it. If you want it to start on boot run it with the `--install` flag. Works on Linux, Mac, and Windows.
You can install it on a Pi just like Pi-hole.
I have a pihole at home (not a Rasperry Pi, gosh I wish they'd ditch the marrying of the two) but to access it I establish a VPN.
Recursive DNS resolvers on the open Internet start getting abused really fast for DNS amplification DDoS attacks (for anyone unaware reading this).
I looked into on-demand but is required a mdm profile and that seemed more trouble than it's worth.
It was surprisingly very easy and straightforward to setup, and working very well! It's most useful on Android/iOS.
One small change I've done is to set the Pi-hole DNS server only on a specific set of VPN connections (using specific ports) in order to have a full, unfiltered VPN if necessary.
1) Are the DNS request sent to oblivion or a fake address is returned instead? If the former, wouldn't a failed DNS request generate some sort of timeout?
2) Would a failed DNS request generate multiple retries to load a resource that is not available? (I can imagine this for application other than browsers).
3) How long until pages with ads will start solving addresses through some sort of script? Like in the section of the page responsible for showing an ad, manually crafting and sending a DNS request to 8.8.8.8 or whatever.
edit: for clarity
You make a DNS query to badsite.com, your local DNS responds with your local http host and you load a pixel image instead of whatever it should have been.
I actually use pfblockerng, it does the same thing without the pretty UI.
Also beware as most ads in your phone apps come from ad intermediaries that are either dynamic or constantly change.
Pi-Hole is a cool project but please take in consideration those two when using it. We are far from the 90's in ad-tech.
Surely Youtube being the size it is has a few Github issues against it saying 'I can't load images because I block the ads'?
I guess what I'm saying is, what is the negative impact of your first point? That some content you want won't come through because the content you don't comes from the same domain?
This is because Youtube serves content and ads from the same domain, so you can't domain-block ad content without blocking all content.
More info on blocking modes [1]. This says the default (and recommended) blocking mode is NULL but it wasn't the case when I recently did my last install. Not sure if it was something with my build or maybe the docs need to be updated.
You will find that failing to access the resource on the other side will make many clients try and try again. On my PiHole I see Philips Hue, Microsoft, or Sonos with tens of thousands of retries triggered by previous failures to contact their destinations.
[0] https://pi-hole.net/2018/05/18/nxdomain-and-null-blocking-wi...
Love it.
If you have any kind of local server running "proper" Linux (not necessarily a pi) it's pretty easy to run pihole on it though - there's a docker image or you can fire up your favourite other Debian-based VM/container image and install using a shell script.
I think you're better off to fire up a Docker instance!
https://hub.docker.com/r/pihole/pihole/
But why do you think OpenWRT is better? Because it has a (somewhat clunky and not as feature rich) adblock solution built it?
So does pfSense with pfBlocker-NG which is also another common adblock solution people use.
But for a basic user to just augment their home network with ad-filtering, way better off to just have add a pihole, than to totally replace their router.
I use a tp-link wr842nd. I even have a Telegram bot on it to interact with it. A Pi would be more powerful, sure, but the router serves my needs.
It's a common-ish practice in the community to have a restrictive pi-hole running in your guest/kids network and a more permissive pi-hole running in the trusted/adults network. Pi-holes require so few resources and maintenance that it's not much burden to run more than one.
It would be a pretty large feature to support separate blocklists per IP range.
Good luck with that. There is a reason they want you to load directly from their ad-network. It's the surest way they have to accurately track valid clicks.
And for guests you can disable PiHole for any time period with a click of the button on its web page.
Or kick your guests/roomates/gf onto a different subnet.
That said though, it is clearly not perfect and could use some work and TLC to take care of. But in case you (or the nest person reading this) wanted some ideas, I thought I'd offer.
There appears to be more effort generally to secure and encrypt the entire DNS system. This is really good and should be applauded and supported. But it will come with a downside... once we reach a future in which DNS records are encrypted end to end, and DNS records are only valid when signed by certain keys, and authenticated NXDOMAIN records... then things like Pi-Hole start to become more difficult as for security of DNS we'll have lost the convenience of changing the answers.
There is always a technical solution, that's the beauty of it :)
It was quick and easy to setup on an existing Ubuntu server install.
I have an R720 and a few old RPi's... so either major overkill hardware or major weaksauce hardware.
256MB RAM? - bloody luxury!
A very quick and a bit rubbish experiment:
$ ping 9.9.9.9
5 packets transmitted, 5 received, 0% packet loss, time 10ms
rtt min/avg/max/mdev = 9.982/10.838/12.531/0.888 ms
$ dig @9.9.9.9 www.google.com A
;; Query time: 13 msec
DNS is pretty quick. Note how I mistakenly use ICMP and a UDP service response time to imply something. If I'd tried to claim that DNS adds about 5ms overhead, I would have been first to put the boot in. The basic result stands though - DNS is quick. The above results are from: my laptop -> wifi -> switch -> switch -> APU2c based pfSense box with quite a lot going on -> modem (FTTC in UK - PPPoE/A) -> ISP .... etc.Oh, an eighth then, I didn't know the raspi had that much RAM.
And this was on a ~2002 laptop in 2011 or so, I'm not old enough to have run it in the 80s on a real potato :(
1. https://pi-hole.net/2018/02/22/coming-soon-ftldns-pi-holes-o...
Currently I'm running it as a docker image on my local server.
will you notice that? No, you will not. But you seem to be concerned about levels of latecy it's impossible to notice anyway, so you need this to get even more (unnoticeable) decreases in latency :)
Then the pihole just queries 1.1.1.1 for you, so your DNS privacy etc is still kept.
so overall in my experience it actually speeds things up considerably (even in the scenario of an already fast dns resolver)
It's pretty nice. Never had an issue with the router's DNS, but OpenWRT also doesn't have the ease of Pi-hole.
One of my favorite parts is being able to show people who come over to visit all the queries their cell phones make to ad networks while we're just carrying on a typical conversation.
Stubby does keep-alives and not restricted to a single thread and opening a new connection per query like Unbound which is why I used it as a forwarder as a few more features than Unbound.
In my Unbound config I have an include to a blocklist generated from https://github.com/StevenBlack/hosts, essentially I pipe the data from that repo through awk [3]
I have an Android TV box so also have a firewall rule to redirect all queries to 8.8.8.8 and 8.8.4.4 port 53 to my local DNS server.
No GUI's, solid and stable. Only thing missing is I need to write a cron job to fetch the latest block list, validate, convert to Unbound format and reload the daemon. It's only a 10 minutes job just something I haven't got round to yet.
OpenBSD is really good for running this stuff.
[1] https://www.nlnetlabs.nl/projects/unbound/about/ [2] https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+Daemon+-+... [3] https://deadc0de.re/articles/unbound-blocking-ads.html
I also use the DNS66 app on Android devices to set my DNS and block ads when I'm using a mobile network.
address=/0.0.0.0/0.0.0.0
addn-hosts=/path/to/dns_blocklist
Then, once a week, cron updates the block lists, invoking something like: wget -qO- "http://winhelp2002.mvps.org/hosts.txt" "http://someonewhocares.org/hosts/zero/hosts" "http://pgl.yoyo.org/adservers/serverlist.php?hostformat=hosts&showintro=0&startdate[day]=&startdate[month]=&startdate[year]=&mimetype=plaintext&useip=0.0.0.0" | grep -w ^0.0.0.0 | sed $'s/\r$//' | sort -u >> /path/to/dns_blocklist
You can pick your favorite blocklists to be more or less aggressive, and you also don't have to update directly from the Internet if you don't inherently trust those blocklist sources. No web UI or Pi-Hole branding. Been working great for years and years.https://openwrt.org/docs/guide-user/services/proxy/privoxy http://www.privoxy.org
Setting this up takes half an hour.
Additionally I am also running strongswan for VPN on the same server.
I am paying 10$ per year for VPS.
RPis are popular and the namesake because they're relatively cheap, low power consumption, but powerful enough - so a good choice for people that don't already have some always-on hardware to run it.
I know a site owner can track visitors with ad-blockers and show them warnings, but that is not it.
All that is needed is really total hour each app is jsed and calculate the ratio.
This assumes equal weights for apps, but can be changed.
You can create bundles for different content types like news vs games as price tiers.
You will never get the big websites that monetise with advertising on board with client side analytics. That would need e.g. server side analytics or DRM on the client side app. Either way I wouldn't touch your app and nor would most that block adverts - and the big websites would probably not be that interested either.
Maybe with reproducible builds you could have a trusted build that people could build at home that also signed the requests with the analytics data. I don't think that the technology to do this exists yet.
-> Donated all money to charity: i don't see how that' possible. Money gets to the company, and gets distributed. If you wanna give money to charity, just do so, and install an ad blocker it's the same idea. You'd miss out on the premium content bundles that I am thinking of.
-> Apps and websites will do so. Many news papers (albeit a losing market in general) offer premium subscription. You are literally making that easier.
-> I do not need trusted builds. People advanced enough to do what you said already can install ad blocker. They still won't get premium content access, and clients can always choose to "verify" -> this actually will happen using public/private key cryptography.
Good luck though.
DNS blocking is configured once for your whole network.
It also updates the hosts files itself on a regular basis, you don't have to remember to do it as a manual task.
It gives you a nice webgui to show you what devices are accessing what hosts, how often they try to access them (at least, how often they request their DNS name) and has different modes of blocking (vs a hosts file has to return 127.0.0.1)
I'm still amazed that they recommend piping curl to bash though...
I'm using it for two years now on my gigabit FTTH connection, running in a LXC container on my router. No problems to report.
Develop a technology that protects ad-supported web sites from ad-blocking scammers ;)
1. Dangerous ads - Cryptominers, viruses/whatever, and the like.
2. Wasteful resource usage - I also block most scripts and unneeded fonts because the value to me of downloading all these add-ons is very low compared to the cost to me through network congestion and possible vulnerabilities.
I pay to support content creators I get value from, and if more creators followed a reasonable, proportional, fee I would support more.