I'm going to disagree with you here. Here is a specific example:mutley wrote: There are no rules with in this method, so no need to determine any rule that caused a block. But if there is a page or some content that's been blocked that you would prefer not to be blocked, the browser will give it to you the DNS / URL that's been blocked. Then just add that to your custom whitelist, and rebuild.
I actually do this with http://www.googleadservices.com, as my wife likes to click the first page of adds that comes back from a google search and just about every source lists http://www.googleadservices.com as ad-tracking (which it is).
The current MVPS HOSTS file is running on my IPFIRE right now, via unbound. There is a website we use to view part spec sheets. One of the urls in MVPS HOSTS prevents these spec sheets from opening. The user gets no feedback from the browser as to which url is causing the spec sheet to not load. All they see is the page failed to load. They don't get any feedback about which url in MVPS HOSTS is causing the page to fail to load.
If IPFIRE's URL Filter was doing the blocking, then it would give more informative feedback via the IPFIRE Block Page. But URL Filter does not handle blocking ads well, because instead of just silently dropping the ads on the page while still showing the pages valid content, it pops up the IPFIRE block page, which confuses the user and slows down their workflow. In some cases, it completely stops their workflow because the user can't get to a page at all.
Blocking ads needs to be transparent in order to be effective. Hence, doing it via DNS makes more sense. Just with the caveat that it will be harder to determine which url is causing a false-positive.