Intercepting domains/requests at the DNS service level or redirecting IP netblocks routes to 127.0.0.1/null route are two very different things.
From my point of view, the DNS level is more efficient and more light on resources.
At IP level/null route blocks more effectively, however it is more cumbersome to manage, and slightly more heavy on CPU usage when used in a wider scale.
Please do bear in mind that using blacklists at DNS level can often reach names in the range of the hundred of thousands, and it is not viable to have such large routing tables.
I myself have investigated doing blacklisting via dnsmasq or BIND. I use DNS blacklisting for adverts, malware and to block my smart TV calling home (LG sites).
I ended up using Response Policy Zone in BIND because it does allow some simple regexps, namely * at the end of names, which greatly reduces the blacklist size. DNS Response Policy Zones
Please do bear in mind RPZ in BIND is supported from 9.8+ BIND, which should be the case in any modern Linux distribution.
As I have the RPZ functionality configured, the domains/DNS names that match the string/regexp simply are answered as non-existent by the BIND DNS server. All the other names that do not match are resolved by the usual process.
As a short example of a few lines of my /etc/bind/rpz.db:
*.ad.lgappstv.com CNAME .
*.yumenetworks.com CNAME .
*.smartclip.net CNAME .
*.smartshare.lgtvsdp.com CNAME .
*.ibis.lgappstv.com CNAME .
*.doubleclick.net CNAME .
*.l.doubleclick.net CNAME .
*.302br.net CNAME .
*.liveadvert.com CNAME .
*.easysuperdownload-1.com CNAME .
*.easysuperdownload-2.com CNAME .
*.itrackpop.com CNAME .
Using your example:
*.this.com CNAME .
*.biz CNAME .
Please do note that it might not be the best of the ideas to block entire TLDs.
BIND is not as picky as Unbound about repetitions. It will allow aaaa.this.com and this.com; however it won't allow this.com to be defined more than one time.
As for the setup of RPZ itself, I will refer you to my answer on this question on Unix & Linux Large zone file for bind9 : ad-blocking
For a ready made similar project using a raspberry PI, please see: Pi-Hole: A Black Hole for Internet Advertsiments That project will also direct you to some known free blacklists.
From https://github.com/pi-hole/pi-hole/blob/master/adlists.default
https://raw.githubusercontent.com/StevenBlack/hosts/master/hosts
# Other lists we consider safe:
http://adblock.gjtech.net/?format=unix-hosts
http://mirror1.malwaredomains.com/files/justdomains
http://sysctl.org/cameleon/hosts
https://zeustracker.abuse.ch/blocklist.php?download=domainblocklist
https://s3.amazonaws.com/lists.disconnect.me/simple_tracking.txt
https://s3.amazonaws.com/lists.disconnect.me/simple_ad.txt
# hosts-file.net list. Updated frequently, but has been known to block legitimate sites.
http://hosts-file.net/ad_servers.txt
# Mahakala list. Has been known to block legitimage domains including the entire .com range.
# Warning: Due to the sheer size of this list, the web admin console will be unresponsive.
#http://adblock.mahakala.is/
# ADZHOSTS list. Has been known to block legitimate domains
#http://optimate.dl.sourceforge.net/project/adzhosts/HOSTS.txt
# Windows 10 telemetry list - warning this one may block windows update
#https://raw.githubusercontent.com/crazy-max/HostsWindowsBlocker/master/hosts.txt
# Securemecca.com list - Also blocks "adult" sites (pornography/gambling etc)
#http://securemecca.com/Downloads/hosts.txt
# Quidsup's tracker list
https://raw.githubusercontent.com/quidsup/notrack/master/trackers.txt
As for whitelisting, apparently it can be done.
If done in a domain by domain basis, it is a matter of setting up a proxy BIND DNS server, that does not have the hints of the root name servers.
However, each allowed domain has to be created with forwarders to a DNS that talks to the outside. This theoretical article sums pretty nicely the idea. Use DNS whitelists to stop malware in its tracks
Using RPZ in BIND again to our rescue, the configuration can be much simpler, and without needing to setup up a proxy DNS server.
As a variation in the configuration of this page, RPZ revisited, you will have a normally configured BIND, with RPZ white lists, and then you will black everything in the normal rpz policy (e.g. * or . ).
options {
....
response-policy {
zone "rpz-white" policy PASSTHRU; // my own white list
zone "rpz-foreign"; // obtained from producer
};
}
Whist the white-listing deny-it-all approach is certainly insane, whitelisting can have it uses to exempt a particular domain that is being hit by a black listing wider match.
BIND 9.9.5-9+deb8u6-Debian (Extended Support Version), indeed I get a message:unknown option 'response-policy'by checking the bind config ;) - Checking how install only bind9 package from backports! – user3450548 Mar 18 '16 at 11:26TLD CNAME .for instance I haveom CNAME .because it is being used for cybersquatters for mistyping .com. In your case, I think a* CNAME A 127.0.0.1will do. I do not have the time to test it for a few hours now. The upper example is actually my blacklist as I do not whitelist. – Rui F Ribeiro Mar 18 '16 at 11:56zone "rpz-foreign" policy DROP;This way works however the request is put in timeout, i want instead a super fast reply so i was thinking of default all on 127.0.0.1 ;) or.. to a local webserver displaying some page or replying with a blank png/gif file. – user3450548 Mar 18 '16 at 12:02