Lokaler Caching-DNS-Resolver mit Unbound: access-control, Forwarding und DNSSEC-Validierung

Ziel

Unbound als cachenden, validierenden DNS-Resolver für ein Netzsegment betreiben: festlegen, wer Abfragen stellen darf, ob der Resolver selbst rekursiv auflöst oder an einen Upstream-Resolver weiterleitet, und sicherstellen, dass die DNSSEC-Validierung aktiv ist.

Voraussetzungen

Unbound ist installiert; ein Netzsegment, dessen Hosts auf diesen Resolver zeigen sollen; ausgehender Zugriff auf das Internet (für Rekursion) oder auf einen Upstream-Resolver (für Forwarding).

Schritte

1. In der server:-Klausel der unbound.conf eine interface:-Zeile für die LAN-Adresse ergänzen (standardmässig lauscht Unbound nur auf localhost). Anschliessend mit access-control:-Zeilen einschränken, wer Abfragen stellen darf, jeweils ein Netzblock plus eine Aktion. Der Netzblock wird als IP4- oder IP6-Adresse angegeben; für einen klassenlosen Netzblock wird die Grösse angehängt. Standardmässig ist nur localhost erlaubt, alles andere wird abgewiesen. refuse beantwortet die Anfrage mit REFUSED, deny verwirft sie ohne Antwort. Auf einer aus dem Internet erreichbaren Schnittstelle keine pauschale Freigabe (allow) setzen, da der Resolver sonst zu einem offenen rekursiven Resolver wird, der sich für DNS-Amplification missbrauchen lässt.
2. Zwischen Rekursion und Forwarding entscheiden. Ohne forward-zone:-Klausel löst Unbound Abfragen selbst auf, indem es die DNS-Hierarchie ab der Root durchläuft. Wird stattdessen eine forward-zone: mit name: "." und einem oder mehreren forward-addr:-Zielen eingetragen, schickt Unbound die Abfragen an einen rekursiven Upstream-Resolver – diese Nameserver-Liste dient als Weiterleitungsziel. Unbound validiert DNSSEC dabei weiterhin auf den Antworten, sofern der Upstream die DNSSEC-Records mitliefert.
3. Die DNSSEC-Validierung konfiguriert lassen: auto-trust-anchor-file: auf einen Pfad setzen, den der Benutzer unbound beschreiben darf (die Pakete von Debian und RHEL setzen bereits einen, befüllt durch unbound-anchor). Die Datei enthält einen Trust Anchor für die Zone, der über RFC-5011-Probes nachgeführt wird, die mehrmals pro Monat laufen. Der Resolver muss daher oft genug online sein, um ihn zu aktualisieren.
4. Vor dem Reload die Syntax prüfen: unbound-checkconf prüft die Konfigurationsdatei des Unbound-DNS-Resolvers auf Syntax- und andere Fehler, ohne den Daemon zu starten.
5. Den laufenden Resolver als root neu laden (unbound-control reload, was auch den Cache leert, oder ein Neustart des Dienstes). unbound-control benötigt control-enable: yes in einer remote-control:-Klausel sowie entweder TLS-Schlüssel, die einmalig mit unbound-control-setup erzeugt werden, oder ein lokales Unix-Socket als control-interface.
6. Einen veralteten oder vergifteten Cache-Eintrag ohne Neustart entfernen: unbound-control flush <name> löscht den Namen aus dem Cache und deckt dabei die gängigen Record-Typen in einem Aufruf ab.

Erwartetes Ergebnis

Abfragen aus dem konfigurierten Netz werden aufgelöst und zwischengespeichert; Abfragen von ausserhalb erhalten REFUSED (bei deny keine Antwort). dig +dnssec zeigt gegen eine validierte Zone das AD-Flag, und eine absichtlich fehlerhaft signierte DNSSEC-Testdomain lässt sich nicht auflösen, statt eine fälschbare Antwort zu liefern.

Grenzen und Prüfbasis

unbound-checkconf findet Syntaxfehler, nicht aber betriebliche Probleme wie ein nicht erreichbares Forward-Ziel – nach einem Reload daher auch die Namensauflösung testen, nicht nur die Konfiguration prüfen. Eine zu weit gefasste access-control-Regel ist eine häufige Ursache für Missbrauch von Resolvern; sie sollte überprüft werden, sobald der Resolver in ein anderes Netz umzieht. auto-trust-anchor-file setzt voraus, dass der Resolver ausreichend durchgehend läuft, um die RFC-5011-Update-Probes abzuschliessen; ein Resolver, der längere Zeit offline war, benötigt unter Umständen einen neu eingespielten Trust Anchor.