BLog

ImprintImpressum
PrivacyDatenschutz
DisclaimerHaftung
Downloads 

Spam-Sperrzonen im DNS des FreeBSD-Home-Servers

Der Betrieb des eigenen Name-Servers ermöglicht, Domains mit unerwünschten Services (Spam) zu sperren, so daß sie jedenfalls über deren Domain-Namen vom internen Netzwerk aus nicht erreichbar sind.

Experimente im DNS

Greifen wir uns doch ein Versuchskaninchen, zum Beispiel DoubleClick heraus. Hierbei handelt es sich um eine der ganz großen Werbe-Schleudern im WWW, und als solche dürfte sie mit ihrer Banner-, Rich-Media- und Suchmaschinen-Werbung so manchem nicht-interessierten Web-Besucher auf unzähligen Seiten auf den Keks gehen. Wir melden uns über ssh als root-User bei unserem Home-Server an und geben den folgenden Befehl ein:

# drill doubleclick.net
>>>>>
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 45271
;; flags: qr rd ra ; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 
;; QUESTION SECTION:
;; doubleclick.net.	IN	A

;; ANSWER SECTION:
doubleclick.net.	300	IN	A	70.32.146.212

;; AUTHORITY SECTION:

;; ADDITIONAL SECTION:

;; Query time: 393 msec
;; SERVER: 127.0.0.1
;; WHEN: Tue Aug 19 10:16:01 2014
;; MSG SIZE  rcvd: 49

Unser Name-Server gibt die Anfrage an die für die Root-Zonen verantwortlichen DNS-Server weiter, und hangelt sich von dort bis zum autorisierten Name-Server für die gesuchte Domain weiter. Von dem erhält er dann im vorliegenden Fall die gegenwärtige IP-Adresse, und reicht diese an den Anfragenden (hier unseren Terminal-Befehl) durch.

Nun besitzt DoubleClick jede Menge Sub-Domains, über die die Werbeinhalte ausgeliefert werden, und diese Sub-Domains führen alle zu unterschiedlichen IP-Adressen, z.B.:

drill ad.de.doubleclick.net
>>>>>
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 8086
;; flags: qr rd ra ; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0 
;; QUESTION SECTION:
;; ad.de.doubleclick.net.	IN	A

;; ANSWER SECTION:
ad.de.doubleclick.net.	86400	IN	CNAME	dart.l.doubleclick.net.
dart.l.doubleclick.net.	300	IN	A	173.194.118.219
dart.l.doubleclick.net.	300	IN	A	173.194.118.220

;; AUTHORITY SECTION:

;; ADDITIONAL SECTION:

;; Query time: 309 msec
;; SERVER: 127.0.0.1
;; WHEN: Tue Aug 19 10:28:34 2014
;; MSG SIZE  rcvd: 92

Was würde passieren, wenn unser Name-Server die Domain-Namen mit den Werbe-Inhalten nicht auflösen kann, und wenn er anstelle der IP-Adresse die Fehlermeldung NXDOMAIN auf die Anfrage eines Web-Browsers zurückgibt? Ganz einfach, der betreffende Web-Browser kann die Werbe-Inhalte nicht anzeigen, und stellt stattdessen je nach Web-Seitengestaltung entweder gar nichts, ein leeres Feld oder ein Platzhaltersymbol dar, jedenfalls würde keine Werbung nachgeladen geschweige denn angezeigt werden.

Wir manipulieren nun einmal die Konfigurationsdatei unbound.conf(5) unseres Name-Servers:

# nano /var/unbound/unbound.conf
>>>>>
server:
        username: unbound
        directory: /var/unbound
        chroot: /var/unbound
        pidfile: /var/run/local_unbound.pid
        auto-trust-anchor-file: /var/unbound/root.key

        outgoing-range: 512
        root-hints: /var/unbound/root-hints.zones
        interface: 127.0.0.1
        interface: 192.168.1.35
        interface: ::1
        access-control: 127.0.0.1 allow
        access-control: 192.168.1.0/24 allow
        access-control: 0.0.0.0/0 deny
        access-control: ::0/0 deny
        private-address: 0.0.0.0/8
        private-address: 127.0.0.0/8
        private-address: 169.254.0.0/16
        private-address: 10.0.0.0/8
        private-address: 172.16.0.0/12
        private-address: 192.168.0.0/16
        private-address: fd00::/8
        private-address: fe80::/10

        local-zone: "doubleclick.net" static​

Durch die zusätzliche Zeile in blau wird die Domain „doubleclick.net“ als statische lokale Zone des Name-Servers angelegt. Es werden aber keine weiteren Angaben gemacht, so daß der Name-Server nicht anders kann als alle Anfragen an diese Zone mit der Fehlermeldung NXDOMAIN zu beantworten. Wir starten den Name-Server-Daemon neu, und prüfen die neue Zone mit dem Befehl host [xxx.]doubleclick.net, und zwar für verschiedene Sub-Domains xxx..

# service local_unbound restart
host doubleclick.net
>>>>>
Host doubleclick.net not found: 3(NXDOMAIN)

host ad.de.doubleclick.net
>>>>>
Host ad.de.doubleclick.net not found: 3(NXDOMAIN)

host ad.br.doubleclick.net
>>>>>
Host ad.br.doubleclick.net not found: 3(NXDOMAIN)

Ab sofort schleudert DoubleClick keine Werbung mehr in unseren Garten.

Was ist mit den anderen Werbe-Schleudern?

Leider gibt es zigtausende davon, und DoubleClick mußte ja auch nur als Versuchskaninchen herhalten. Ausserdem wäre es geradezu unmoralisch um nicht zu sagen wettbewerbswidrig, willkürlich nur DoubleClick zu sperren, und alle anderen durchzulassen. Wir müssen im Grunde nur die Domains der anderen wissen, und hängen sie Alle, und zwar nicht auf, sondern an, und zwar über die Sperr-Zonenliste /var/unbound/local-void.zones an die Name-Server-Konfigurationsdatei.

Es werden von verschiedenen Seiten Hosts-Listen über Werbungs-, Tracking-, Spam- und Mal-Ware-Domains geführt. Diese Hosts-Listen müssen „nur“ konsolidiert und in das Void-Zones-Format konvertiert werden. Auf GitHub habe ich dazu die void-zones-tools zur freien Verfügung gestellt. Dort befindet sich auch eine Anleitung wie genau zu verfahren ist. Siehe auch dns/void-zones-tools.

Copyright © Dr. Rolf Jansen - 2018-10-02 18:32:59

PROMOTION