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...
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.
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.
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