Unbound als lokaler DNS-Resolver fürs Mailsystem

Wie du mit einem eigenen DNS-Server deinen Spamfilter verbessern kannst

Dieser Tage hab ich wieder etwas an meinem privaten Mailserver geschraubt und mich dabei auch eingehender mit Postscreen beschäftigt. Dabei ist mir aufgefallen, dass die Abfrage von Whitelists nicht so klappt, wie ich mir das vorgestellt hab. Der Grund dafür war schnell gefunden - ich nutzte den DNS-Server meines Providers, der jedoch aufgrund zu vieler Abfragen kaum Ergebnisse liefert.

Sowohl Blacklists als auch Whitelists wie DNSWL fragen die IP-Adressen einliefernder Mailserver per DNS ab. Die Listenbetreiber gehen dabei manchmal dazu über, nur noch eine bestimmte Anzahl an Abfragen kostenfrei zu ermöglichen - bei DNSWL beispielsweise 100.000 Abfragen innerhalb von 24 Stunden. Wird dieser Schwellwert überschritten, dann werden keine oder ungültige Ergebnisse zurückgeliefert und somit auch die Spamerkennungsrate negativ beeinflusst.

Wer einen kleinen Mailserver betreibt und nun meint, diese Grenze so schnell nicht zu erreichen, verkennt dabei ein wichtiges Detail: Da die Abfragen über DNS-Server erfolgen, wird gerade nicht die IP des eigenen Servers genutzt, sondern in der Regel die der Provider-Nameserver. In meinem Fall, bei einem großen deutschen Anbieter, machen das viele Kunden so - und schwupps, ist die Grenze erreicht. Auch der vielerorts beliebte Eintrag der Google DNS-Server führt übrigens zum selben Ergebnis.

In meinem Fall zeigte sich das daran, dass die Whitelist-Abfrage von Postscreen nur bedingt funktioniert hat. Abhilfe schafft die Installation eines eigenen DNS-Servers, der weitere Vorteile wie beispielsweise lokales Caching mit sich bringt und nicht zuletzt dafür sorgt, dass die DNS-Abfrage von der IP des eigenen Servers ausgeht, die in der Regel das Abfragelimit noch nicht erreicht hat.

Mit Unbound steht dabei eine leichtgewichtige Alternative zur Verfügung, die grundlegende Funktionalität bereitstellt aber nicht mit der Komplexität größerer DNS-Software aufwartet.

Installation

Mein Testystem besteht aus einer Installation mit Ubuntu 16.04 samt Postfix und amavis. Als DNS-Server sind die des Providers vorkonfiguriert. Die Installation von Unbound geht dabei recht einfach vonstatten: Mit einem einfachen

apt-get install unbound

findet das Paket seinen Weg auf den Rechner. In neueren Versionen wie unter Ubuntu 16.04 wird das Tool unbound-anchor zur Installation der Schlüssel bereits automatisch bei jedem Start aufgerufen.

Händisch eingerichtet und idealerweise später regelmäßig per Cronjob aktualisiert werden sollte indes die Datei, die auf die jeweils gültigen Root-Nameserver verweist. Das lässt sich am einfachsten mittels

wget https://www.internic.net/domain/named.cache -O /etc/unbound/root.hints

bewerkstelligen. Damit ist die Grundinstallation abgeschlossen.

Konfiguration

Anschließend geht es an die Konfiguration, die Ubuntu-typisch auf einzelne Dateien aufgeteilt ist. Alle im Verzeichnis /etc/unbound/unbound.conf.d/ befindlichen und auf .conf endenden Dateien werden für die Bestimmung der Optionen herangezogen.

Auf meinem Server habe ich dafür in einer separaten Datei names /etc/unbound/unbound.conf.d/z9999-user.conf folgende Einstellungen vorgenommen:

server:
prefetch: yes
qname-minimisation: yes
use-caps-for-id: yes
statistics-interval: 600
statistics-cumulative: yes
root-hints: "/etc/unbound/root.hints"
hide-identity: yes
hide-version: yes
unwanted-reply-threshold: 10000000

Diese weisen Unbound vereinfacht gesagt an:

besonders oft angefragte Einträge automatisch vorzuladen (prefetch)
möglichst wenig Informationen bei der Abfrage zu übermitteln (qname-minimisation)
gefälschte Antworten möglichst zu erkennen und herauszufiltern (use-caps-for-id)
regelmäßig kumulierte Statistiken in die Logdatei auszugeben (statistics-interval und statistics-cumulative)
die gerade geladene Datei mit Root-Nameservern zu berücksichtigen (root-hints)
mit Informationen zu sich selbst bei Abfragen zu geizen (hide-identity und hide-version)
und bei einer gewissen Zahl von unerwünschten Antworten den Cache automatisch zu leeren (unwanted-reply-threshold)

Die Konfiguration lässt sich anschließend über den Befehl

unbound-checkconf

auf mögliche Fehler prüfen. Lautet die Ausgabe “no errors”, dann kann Unbound in Betrieb genommen werden. Dabei ist die sicherste Variante, den Dienst zuerst herunterzufahren und anschließend neu zu starten:

service unbound stop
service unbound start

Erster Test

Im nächsten Schritt sollte getestet werden, ob das Programm auch korrekt funktioniert. Am einfachsten geht das mit

dig dnswl.org @127.0.0.1

Eine korrekte Antwort sieht auszugsweise so aus:

;; ANSWER SECTION:
dnswl.org. 86396 IN A 88.198.55.172
;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sun Sep 24 13:56:19 CEST 2017
;; MSG SIZE rcvd: 54

Gibt der Server eine ähnliche Meldung aus, hat soweit alles geklappt.

DNS-Resolver einstellen

Jetzt kann der Server angewiesen werden, Unbound auch zu benutzen. Die meisten Linux-Systeme greifen zur Konfiguration des Nameservers auf die Datei /etc/resolv.conf zu. Neben einigen weiteren Optionen sind hier in den Zeilen beginnend mit nameserver nacheinander die IP-Adressen der abzufragenden Nameserver vorgegeben. Dabei fragt das System zunächst die erste gelistete Adresse ab, erst dann die zweite, anschließend die dritte und so weiter.

Es bietet sich also an, Unbound als ersten Resolver einzutragen und zur Sicherheit darunter die DNS-Server des Providers stehen zu lassen. Fällt der lokale Resolver aus, so funktioniert dann die Namensauflösung dennoch weiterhin. Im Fall der Google DNS-Server sieht das beispielsweise so aus:

nameserver 127.0.0.1
nameserver 8.8.8.8
nameserver 8.8.4.4

Wichtiger Hinweis: Je nach genutztem System (mit oder ohne DHCP, mit oder ohne resolvconf) werden Einstellungen in der /etc/resolv.conf spätestens beim Neustart überschrieben und Unbound somit nicht mehr genutzt! Falls du die für dein System passende Einstellung findest, freue ich mich über Beispiele in den Kommentaren. ;-) Abschließend kannst du mit einem

dig dnswl.org

(diesmal also ohne @127.0.0.1) testen, ob die DNS-Abfrage im System funktioniert. Die Ausgabe ;; SERVER: 127.0.0.1#53(127.0.0.1) zeigt an, dass der lokale Unbound nun automatisch genutzt wird.

Ausblick

Unbound beherrscht noch einige weitere Funktionen, über die die Manpage Auskunft gibt.

Die oben vorgestellte Konfiguration sollte dafür sorgen, dass Unbound nur auf dem lokalen Interface lauscht, dennoch empfiehlt es sich, die Firewall entsprechend zu konfigurieren, damit keine Abfragen von außerhalb durchgelassen werden. Wer fail2ban nutzt, der findet dort auch eigene Regeln für DNS-Abfragen, die zusätzlich aktiviert werden können.

Abschließend sei noch der Hinweis angebracht, sich insbesondere bei kommerzieller Nutzung der Black- und Whitelists mit den Bedingungen zu befassen und ggf. einen kostenpflichtigen Zugang zu beantragen. Ein lokaler DNS-Resolver kann dabei helfen, den jedermann angebotenen Zugang zu nutzen, darf aber nicht zur Umgehung der Bedingungen eingesetzt werden.