Update voor Unbound als privé-nameserver en adblocker
Gebruik Unbound als privé-nameserver en adblocker
De gangbare routers hebben maar simpele name-resolving-mogelijkheden, dus klinkt een eigen DNSserver in je netwerk wel aantrekkelijk.
De DNS-server Unbound is heel flexibel te gebruiken. In de artikelen over Unbound hebben we laten zien hoe je de software installeert voor alle gangbare name-resolving voor pc's en smartphones in een lokaal netwerk en hoe je de DNS-gegevens valideert [1,2].
Je kunt Unbound daarbij ook gebruiken als adblocker. Dat werkt als volgt: de domeinnamen van veel servers die reclamecontent leveren zijn bekend. Daarom kun je die op een zwarte lijst zetten en vervolgens alle toegang tot die servers blokkeren (blacklist). Er zijn verschillende manieren om zo'n blacklist aan te maken. Onder de verzamelnaam 'AdAway's default hosts sources' staan op GitHub meerdere bronnen voor adblock-lijsten. Die zien er allemaal uit als een hosts-bestand (/etc/ hosts) en zijn in principe ook geschikt voor onze Unbound-configuratie. We hebben de MOAB-lijst (MOAB = Mother of Ad-Block) van het XDA-developersforum gebruikt. Via de link onderaan dit artikel komt je bij de laatste versie van die lijst.
Ook die lijst is in het format van het Unix-hosts-bestand gehouden. Je kunt hem downloaden en converteren zodat hij geschikt is voor Unbound. Dat converteren kan met het script moab2unbound.sh, dat ook bij de link staat. Maar voordat je dat gaat doen moet je je realiseren dat als het bestand /etc/unbound/conf.d/moab. conf al bestaat, dat het dan overschreven wordt. Maak daar voor alle zekerheid eerst een kopietje van.
Download vervolgens het scriptarchief via de link onderaan en pak het uit op de desktop. Het script moab2unbound. sh downloadt het MOAB-bestand en converteert het met behulp van awk voor Unbound:
wget -O moab.zip "https://forum.xda- developers.com/attachment.php?attachme ntid=4178971&d=1497247267" unzip moab.zip touch whitelist cat ./system/etc/hosts | awk 'NR==1{ print "server:"}; {sub(/^\./, "", $2);sub(/\.$/, "", $2); print " local-data: \"" $2". 3600 IN A 127.53.53.1\""}' | grep -v -f whitelist > /etc/unbound/conf.d/moab. conf rm -rf ./system rm moab.zip unbound-control reload
Het script gebruikt domeinnamen voor local-data-items en kent daar een nietbestaand loopback-adres aan toe. Verzoeken aan webservers die reclame leveren worden daarmee verwezen naar het luchtledige. Na het aanmaken van het bestand moab.conf start het script de Unbound-server opnieuw op. Of de adblocker werkt, kun je op de server met het volgende commando testen:
dig @localhost doubleclick.com +short
Dat commando moet het ip-adres 127.53.53.1 opleveren.
Whitelist voor Unbound
Als je eenmaal een blacklist hebt, ben je niet ver verwijderd van het maken van een whitelist, oftewel een filter dat bepaalde domeinen in principe niet blokkeert. Een dergelijk positief filter is eigenlijk net zo makkelijk te maken als een negatief. Een voorbeeld daarvan staat in het tekstbestand 'whitelist'. Daar zet je domeinnamen of delen van domeinnamen in die door de adblockfilters genegeerd moeten worden.
Op elke regel van een blacklist mag maar één domeinnaam staan. Wordt een naam zonder inleidende aanhalingstekens aangegeven, dan mogen alle domeinnamen die die naam bevatten bezocht worden. Unbound maakt dan zoals gebruikelijk van de naam een ipadres en geeft dat door aan de pc die erom gevraagd had. Met boek.nl kun je bijvoorbeeld voorkomen dat boek.nl en leesboek.nl geblokkeerd worden, maar dat geldt niet voor boekhandel.nl.
Als alleen een enkele domeinnaam uitgezonderd moet worden van het blacklist-filter, moet die in de whitelist voorafgegaan worden door een dubbel aanhalingsteken (") en eindigen met een punt (.) – bijvoorbeeld zo:
"boek.nl.
Deze regel verhindert dat het domein boek.nl (en alleen die domeinnaam) geblokkeerd wordt. Het voorbeeldbestand 'whitelist', dat ook bij de link hieronder staat, bevat dan ook alleen die domeinnaam. (nkr)
Literatuur
[1] Andreas Itzchak Rehberg, Zelfoplossend, Name-resolution inclusief databeveiliging thuis, c't 7-8/2017, p.138
[2] Carsten Strotmann, Privacy in de tunnel, Domain Name Service: databeveiliging zelf maken, c't 12/2017, p.124
ww.ct.nl/softlink/1804135