OPNsense - Unbound DNS Resolver

Aus maxTechCorner

Auf einen Blick

Gilt fürOPNsense 26.1 und 26.7 (Services → Unbound DNS, im Kern enthalten), Unbound 1.26
BereichIT-Security
Dauerca. 30 Minuten (Grundkonfiguration, DHCP-Namen, Blocklisten)
RechteAdministrator (OPNsense-WebUI)
StandOktober 2026 (OPNsense 26.7.5, Unbound 1.26.1)

Unbound DNS in OPNsense ist der Standard-DNS-Server der Firewall: ein schneller, validierender und cachender rekursiver Resolver von NLnet Labs. Er beantwortet die Namensauflösung für alle internen Netze, prüft Antworten per DNSSEC, löst interne Namen über Host Overrides und DHCP-Registrierung auf, leitet bei Bedarf an Domain Controller oder verschlüsselt per DNS over TLS an externe Resolver weiter und filtert Werbung, Tracking und Schadsoftware-Domains über DNS-Blocklisten.

Dieser Artikel beschreibt die Einrichtung mit OPNsense 26.7: Grundeinstellungen, das empfohlene Zusammenspiel mit Dnsmasq für DHCP-Namen, Active-Directory-Weiterleitung, DNS over TLS, Blocklisten mit Policies pro Netz, Absicherung gegen DNS-Umgehung sowie Fehlersuche.

Unbound DNS in OPNsense: Aufbau und Menü

Unbound ist in OPNsense fest im Kern enthalten und nach der Erstinstallation bereits aktiv. Der Einrichtungsassistent kombiniert Unbound für DNS mit Dnsmasq für DHCP (IPv4, IPv6 und Router Advertisements). Unter Services → Unbound DNS finden sich:

Menüpunkt Zweck
General Aktivieren, Port, Schnittstellen, DNSSEC, DNS64, DHCP-Registrierung (nur ISC), Local Zone Type
Overrides Feste Einträge für interne Hosts (A, AAAA, MX, TXT) mit Aliassen und optionalem PTR
Advanced Härtung, Datenschutz, Cache, Prefetch, Serve Expired, Logging
Access Lists Wer den Resolver befragen darf
Blocklists DNS-Blocklisten (DNSBL) mit Policies pro Quellnetz
Query Forwarding Weiterleitung einzelner Domains oder aller Anfragen an andere DNS-Server
DNS over TLS Weiterleitung über TLS (Port 853)
Statistics / Log File Zähler, Cache-Trefferquote, Meldungen des Dienstes

Ausführliche Auswertungen (Top-Domains, blockierte Anfragen, Clients) bietet Reporting → Unbound DNS, sobald die Statistik dort aktiviert ist.

Rekursion oder Weiterleitung?

Betriebsart Funktionsweise Vorteile Nachteile
Rekursiv (Standard) Unbound fragt selbst die Root-, TLD- und autoritativen Server Keine Abhängigkeit von einem Anbieter, DNSSEC-Validierung, kein zentraler Dritter sieht alle Anfragen Anfragen gehen unverschlüsselt an die autoritativen Server
Query Forwarding (alle Anfragen) Weiterleitung an Provider- oder öffentliche Resolver Einfach, ggf. Filter des Upstream-Anbieters Abhängigkeit vom Upstream; DNSSEC nur, wenn der Upstream es unterstützt
DNS over TLS Weiterleitung verschlüsselt über Port 853 Schutz gegen Mitlesen auf der Leitung Der Upstream-Anbieter sieht alle Anfragen

Für die meisten Unternehmen ist der rekursive Betrieb mit DNSSEC die beste Wahl; DNS over TLS ist sinnvoll, wenn die Leitung (z. B. ein Provider mit DNS-Manipulation) nicht vertrauenswürdig ist.

Unbound DNS auf der OPNsense: Clients fragen Unbound; interne Zonen gehen an Dnsmasq (DHCP-Namen) bzw. an die Domain Controller, alles andere wird rekursiv mit DNSSEC oder per DNS over TLS aufgelöst – Blocklisten mit Policies pro Netz filtern unerwünschte Domains.

Schritt 1: Grundeinstellungen (General)

Einstellung Empfehlung
Enable Unbound aktiv
Listen Port 53
Network Interfaces nur interne Schnittstellen (LAN, VLANs, VPN) statt All – WAN nie auswählen
Enable DNSSEC Support aktivieren – Antworten werden kryptografisch geprüft, gefälschte Einträge verworfen
Register ISC DHCP4 Leases / Register DHCP Static Mappings nur bei Einsatz des Legacy-Plugins os-isc-dhcp; mit Dnsmasq stattdessen Query Forwarding (Schritt 2)
Local Zone Type transparent (Standard)
Flush DNS Cache during reload aus, damit der Cache nach Konfigurationsänderungen erhalten bleibt
Force SafeSearch optional, z. B. für Schulen oder Gastnetze (Google, Bing, DuckDuckGo, YouTube u. a.)

Damit die Firewall selbst Unbound verwendet, unter System → Settings → General keine externen DNS-Server eintragen bzw. Allow DNS server list to be overridden by DHCP/PPP on WAN deaktivieren. Unbound benötigt keine Upstream-Server, solange er rekursiv arbeitet.

Schritt 2: Interne Namen – Dnsmasq-DHCP anbinden

Seit OPNsense 26.1 ist Dnsmasq der Standard-DHCP-Server und für kleine und mittlere Umgebungen (unter 1.000 Clients) empfohlen. Dnsmasq registriert die Hostnamen der Clients selbst; Unbound fragt diese Namen per Query Forwarding ab. Die OPNsense-Dokumentation empfiehlt dafür:

  1. Services → Dnsmasq DNS & DHCP → General: Enable und Listen Port 53053 (damit Dnsmasq nicht mit Unbound auf Port 53 kollidiert).
  2. Pro DHCP-Bereich eine eigene interne Domain verwenden, z. B. lan.internal für 192.168.1.0/24.
  3. Services → Unbound DNS → Query Forwarding pro Bereich zwei Einträge anlegen:
Domain Server IP Server Port
lan.internal 127.0.0.1 53053
1.168.192.in-addr.arpa (Rückwärtsauflösung) 127.0.0.1 53053

Als interne Domain eignet sich .internal, die von der ICANN ausdrücklich für private Netze reserviert ist. Die Endung .local ist für mDNS (Bonjour/Avahi) vorgesehen und sollte nicht verwendet werden.

Kea DHCP (für große Umgebungen und HA mit Lease-Synchronisation) meldet Hostnamen seit OPNsense 26.1 per DDNS (RFC 2136) – allerdings nur an einen DNS-Server, der dynamische Updates annimmt (z. B. das BIND-Plugin mit TSIG-Schlüssel; AD-integrierte Windows-Zonen mit „nur sicheren Updates“ verlangen GSS-TSIG, das die OPNsense-Oberfläche nicht anbietet). Unbound selbst nimmt keine dynamischen Updates an; die so gepflegte Zone wird dann per Query Forwarding eingebunden.

Host Overrides

Unter Overrides werden feste Einträge gepflegt, z. B. nas.example.internal → 192.168.1.20 (Typ A/AAAA, auch MX und TXT), mit Add PTR record für die Rückwärtsauflösung. Über Aliases erhält ein Host weitere Namen; mit * als Hostname entsteht ein Wildcard-Eintrag. Typischer Einsatz: Split DNS – ein öffentlicher Name wie cloud.example.com wird intern direkt auf die interne Adresse aufgelöst, statt den Umweg über die öffentliche IP zu nehmen.

Schritt 3: Active Directory und andere interne Zonen

Für eine AD-Domain fragt Unbound die Domain Controller direkt:

  • Query Forwarding: Domain ad.example.internal → Server IP des ersten DC, Port 53; zweiten Eintrag mit derselben Domain für den zweiten DC.
  • Zusätzlich die Rückwärtszonen der Servernetze (z. B. 10.168.192.in-addr.arpa) an die DCs weiterleiten.
  • Liefert der DC private Adressen für eine Domain, die Unbound als öffentlich ansieht, greift der Rebind-Schutz – die Domain dann unter Advanced → Private Domains eintragen.
  • Ist die interne Zone nicht DNSSEC-signiert, aber eine gleichnamige öffentliche Zone signiert, die Domain unter Advanced → Insecure Domains eintragen.

Alternativ zeigen Windows-Clients direkt auf die DCs, und diese nutzen Unbound als Forwarder für alle anderen Namen.


HinweisLaut OPNsense-Dokumentation findet für Weiterleitungen mit einer bestimmten Domain keine DNSSEC-Validierung statt, da der Zielserver meist ein lokaler Controller ist. Bei einer Weiterleitung aller Anfragen an einen Upstream ohne DNSSEC-Unterstützung erreichen die Antworten die Clients nicht, solange DNSSEC aktiv ist.

Schritt 4: DNS over TLS (optional)

Services → Unbound DNS → DNS over TLS – Einträge ohne Domain gelten für alle Anfragen:

Anbieter Server IP Port Verify CN
Quad9 9.9.9.9 / 149.112.112.112 853 dns.quad9.net
Cloudflare 1.1.1.1 / 1.0.0.1 853 cloudflare-dns.com

Das Feld Verify CN ist Pflicht für die Zertifikatsprüfung – ohne es ist die Verbindung zwar verschlüsselt, aber nicht gegen Man-in-the-Middle geschützt. Mindestens zwei Server eintragen. Forward first lässt Unbound bei SERVFAIL auf eigene Rekursion zurückfallen – das erhöht die Verfügbarkeit, hebelt aber die gewünschte Verschlüsselung im Fehlerfall aus. Spezifische Domain-Einträge (z. B. für AD) haben in Query Forwarding und DNS over TLS stets Vorrang vor dem Eintrag für alle Anfragen.

Schritt 5: DNS-Blocklisten (DNSBL) mit Policies

Services → Unbound DNS → Blocklists filtert Domains bereits bei der Namensauflösung – für alle Geräte im Netz, ohne Software auf den Clients:

  • Type of DNSBL: vordefinierte Listen, u. a. Hagezi (Stufen LIGHT bis ULTIMATE, Threat Intelligence Feeds, DoH/VPN/TOR/Proxy Bypass, Gambling, Social Networks), abuse.ch ThreatFox, OISD, AdGuard, EasyList/EasyPrivacy und Steven Black. Eigene Listen über URLs of Blocklists.
  • Allowlist Domains (reguläre Ausdrücke erlaubt), Blocklist Domains (exakte Treffer) und Wildcard Domains (inklusive aller Subdomains).
  • Source Net(s): Es lassen sich mehrere Policies für unterschiedliche Quellnetze anlegen – etwa Threat Intelligence für alle Netze, zusätzlich Werbe- und Social-Media-Sperren nur im Gäste-WLAN.
  • Return NXDOMAIN statt der Standardadresse 0.0.0.0 lässt Clients schneller aufgeben.

Mit dem eingebauten Tester lässt sich prüfen, ob und durch welche Policy eine Domain blockiert wird; Reporting → Unbound DNS zeigt die blockierten Anfragen pro Client. Als zusätzliche kommerzielle Quelle kann Q-Feeds seine Domain-Feeds direkt als Unbound-Blockliste registrieren.


HinweisFür Unternehmen zuerst mit Sicherheitslisten beginnen (z. B. Hagezi Threat Intelligence Feeds oder ThreatFox) und Werbelisten zurückhaltend einsetzen – aggressive Listen wie ULTIMATE blockieren regelmäßig legitime Geschäftsanwendungen. Freigaben über die Allowlist dokumentieren.

Schritt 6: Absicherung und Härtung

Zugriff beschränken

  • Network Interfaces auf interne Schnittstellen begrenzen und kein Port 53 auf dem WAN freigeben – sonst entsteht ein offener Resolver, der für DDoS-Verstärkungsangriffe missbraucht wird.
  • Access Lists: Für die gewählten Schnittstellen legt OPNsense automatisch ACLs an. Netze, die über VPN oder Router erreicht werden (z. B. WireGuard- oder IPsec-Gegenstellen), müssen manuell mit Allow eingetragen werden. Die Default Action (Standard: Allow) kann auf Refuse oder Deny gestellt werden, damit nur explizit freigegebene Netze Antworten erhalten.

DNS-Umgehung verhindern

DNS-Filter und interne Namen wirken nur, wenn alle Clients Unbound verwenden:

  • Unter Firewall → NAT → Destination NAT DNS-Anfragen (TCP/UDP 53) aus den internen Netzen an fremde Server auf Unbound umleiten (Ziel 127.0.0.1, Port 53), alternativ per Regel blockieren.
  • DNS over TLS (TCP 853) ausgehend aus den Client-Netzen sperren.
  • DNS over HTTPS lässt sich nur über Blocklisten bekannter DoH-Anbieter (z. B. Hagezi DoH/VPN/TOR/Proxy Bypass) und Browser-Richtlinien eindämmen – in Firefox verhindert die Canary-Domain use-application-dns.net (per Override mit NXDOMAIN) die automatische DoH-Aktivierung.

Advanced-Optionen

Option Empfehlung
Hide Identity / Hide Version aktivieren
Prefetch Support / Prefetch DNS Key Support aktivieren – häufig genutzte Einträge werden vor Ablauf aktualisiert
Harden DNSSEC Data aktiv lassen
Harden Below NXDOMAIN (seit 26.1) aktivieren, bei Problemen mit sehr alter Software deaktivieren
Aggressive NSEC aktivieren (RFC 8198) – weniger Anfragen dank validiertem Cache
Strict QNAME Minimisation optional für mehr Datenschutz; kann bei fehlerhaften autoritativen Servern zu Ausfällen führen
Rebind protection networks Standard beibehalten – schützt vor DNS-Rebinding-Angriffen
Serve Expired Responses optional: liefert abgelaufene Einträge, wenn ein autoritativer Server gerade nicht erreichbar ist
Log Queries / Log Replies nur zur Fehlersuche – erzeugt große Logs und personenbezogene Daten

Unbound im Zusammenspiel mit anderen Diensten

  • VPN-Clients: Bei WireGuard und OpenVPN die Tunneladresse der Firewall als DNS-Server an die Clients geben und das Tunnelnetz in den Access Lists erlauben; nach dem Zuweisen neuer Schnittstellen Unbound neu starten.
  • Firewall-Aliase: Aliase vom Typ Host(s) mit DNS-Namen werden über den Resolver der Firewall aufgelöst.
  • Zenarmor und Suricata arbeiten auf Netzwerkebene und ergänzen die DNS-Filterung, ersetzen sie aber nicht – siehe OPNsense - Zenarmor Next-Generation-Firewall und OPNsense - Suricata Intrusion Detection und Prevention.
  • SIEM: Unbound-Logs und blockierte Anfragen lassen sich mit dem Wazuh-Agent auswerten.

Typische Probleme und Lösungen

Symptom Ursache und Lösung
Clients aus VPN oder anderen Subnetzen erhalten REFUSED Netz fehlt in den Access Lists – ACL mit Allow anlegen.
DHCP-Namen werden nicht aufgelöst Mit Dnsmasq: Query Forwarding für Domain und Reverse-Zone auf 127.0.0.1:53053 fehlt bzw. Domain des DHCP-Bereichs passt nicht. Mit Kea: DDNS an einen updatefähigen DNS-Server (z. B. BIND mit TSIG) konfigurieren und diese Zone per Query Forwarding einbinden.
Interne Namen liefern keine Antwort, obwohl der DC sie kennt Rebind-Schutz verwirft private Adressen – Domain unter Private Domains eintragen.
SERVFAIL für einzelne Domains DNSSEC-Fehler der Zone (Log SERVFAIL bzw. Log validation level aktivieren) oder Upstream ohne DNSSEC beim Forwarding.
Webseiten oder Apps funktionieren nicht mehr Blocklist-Treffer – im Tester bzw. Reporting prüfen und Domain auf die Allowlist setzen.
Unbound startet nach Änderung nicht Syntax in eigenen Erweiterungen unter /usr/local/etc/unbound.opnsense.d/ oder Portkonflikt mit Dnsmasq (Port 53 doppelt belegt).
Firewall selbst löst nicht auf Unter System → Settings → General falsche DNS-Server oder Do not use the local DNS service as a nameserver for this system aktiv.

Für Tests eignet sich Interfaces → Diagnostics → DNS Lookup oder von einem Client aus nslookup bzw. dig gegen die Firewall-Adresse; Zähler und Cache-Trefferquote zeigt Services → Unbound DNS → Statistics.

Fazit

Unbound DNS macht die OPNsense zum zentralen, sicheren Resolver des Netzwerks: rekursiv und DNSSEC-validierend, mit internen Namen aus Dnsmasq, Weiterleitung an Active Directory, optional verschlüsselt per DNS over TLS und mit Blocklisten, die per Policy für jedes Netz passend filtern. Entscheidend für die Wirkung sind saubere Access Lists und eine konsequente Umleitung aller DNS-Anfragen auf die Firewall.

Unterstützung von m.a.x. it

Sie möchten DNS, DHCP und DNS-Filterung auf Ihrer Firewall sauber aufsetzen oder von einer Altlösung migrieren? m.a.x. it unterstützt Sie als OPNsense-Gold-Partner mit OPNsense-Firewall-Services von m.a.x. it und einer Managed Firewall von m.a.x. it.

Siehe auch

Links und Quellen


Über m.a.x. it Die m.a.x. Informationstechnologie AG ist seit über 30 Jahren IT-Partner mittelständischer und großer Unternehmen in München und bietet maßgeschneiderte Lösungen und Services in den Bereichen Cloud, Cybersecurity, Netzwerk, Windows, Linux und Softwareentwicklung. Sie haben eine Frage zu diesem Artikel oder brauchen Unterstützung? Kontakt aufnehmen

Abgerufen von „http://techcorner.max-it.de/index.php?title=OPNsense_-_Unbound_DNS_Resolver&oldid=3990“