Bering-uClibc 6.x - User Guide - Advanced Topics - Setting Up Ad blocking with dnsmasq
|Setting Up Ad blocking with dnsmasq|
|Prev||Bering-uClibc 6.x - User Guide||Next|
There is a lot of info on the net about setting
dnsmasq to block advertisements, trackings, etc.. LEAF Bering-uClibc 6.x comes with
dnsmasq already installed, so here is a quick guide that shows a simple setup that will filter out advertisements sites from web pages on your networked devices, how lucky can we get !
- Enter the command:
wget -O - http://pgl.yoyo.org/as/serverlist.php?hostformat=dnsmasq-server | grep server= > /etc/dnsmasq.d/adblock.list
- Check the file
/etc/dnsmasq.d/adblock.list, make sure you have a list of servers with the following format:
server=/101com.com/ server=/101order.com/ server=/123found.com/ ... server=/zeusclicks.com/ server=/zintext.com/ server=/zmedia.com/ server=/zv1.november-lax.com/
/etc/dnsmasq.confand enter near the end:
That's it, all the nasty ads should be gone! (Well a bunch of them!)
- Hum yeah! Don't forget to save your configuration, a simple:
lrcfg s) Save configuration
... In dnsmasq "address" and "server" do different things. address=/example.org/127.0.0.1 would return 127.0.0.1 for any DNS queries for example.org and any subdomains. server=/example.org/127.0.0.1 tells dnsmasq to forward any DNS queries for example.org or subdomains to a DNS server located at the 127.0.0.1 IP. So "address" should be used if you're going to supply an IP that the domain resolves to. Using server=/example.org/ (without any IP) makes the dnsmasq server authoritative for that domain. It will then look in its own /etc/hosts (and DHCP leases) file to see if the domain has an IP listed. If not then it'll respond with an NX Domain. I personally think this is a more elegant solution than responding with an IP, as there's no chance of this potentially causing delays as the browser attempts to pull ads from the resolved IP, but some people prefer the IP method so they can run a webserver serving transparent gifs. ...
You want to see if this works, well try this command on any Linux machine or Mac you might be fortunate enough to have connected on your LEAF firewall:
$ time nslookup 101com.com
You should get something like this:
Server: 192.168.1.254 Address:192.168.1.254#53 ** server can't find 101com.com: NXDOMAIN real 0m0.030s user 0m0.004s sys 0m0.012s
- We get a non existant domain for 101com.com.
- The "real 0m0.030s" measures the first time response for this server.
- Let's do a second "time nslookup 101com.com" to see what is the new response time since 101com.com is now in dnsmasq cache:
time nslookup 101com.com
and we get:
Server: 192.168.1.254 Address:192.168.1.254#53 ** server can't find 101com.com: NXDOMAIN real 0m0.014s user 0m0.005s sys 0m0.005s
We are now down to 14 msec response time... looks like it works faster, but your mileage may vary ! Anyway, this gives a rough guess of the delay this type of filtering generates.
The usual "Enjoy" takes a whole new lot of sense now !