imported>TechCorner-Redaktion: Verlinkung auf den Artikel OPNsense - Kea DHCP mit Hochverfügbarkeit ergänzt

2026-10-08T00:00:00Z

Verlinkung auf den Artikel OPNsense - Kea DHCP mit Hochverfügbarkeit ergänzt

Neue Seite

{{Steckbrief
| gilt_fuer = OPNsense 26.1 und 26.7 (Services → Unbound DNS, im Kern enthalten), Unbound 1.26
| bereich = IT-Security
| dauer = ca. 30 Minuten (Grundkonfiguration, DHCP-Namen, Blocklisten)
| rechte = Administrator (OPNsense-WebUI)
| stand = Oktober 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:
{| class="wikitable"
! 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? ===
{| class="wikitable"
! 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.

[[Datei:OPNsense-Unbound-DNS.png|thumb|center|750px|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) ==
{| class="wikitable"
! Einstellung !! Empfehlung
|-
| '''Enable Unbound''' || aktiv
|-
| '''Listen Port''' || <code>53</code>
|-
| '''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 '''[[OPNsense - Dnsmasq DHCP-Server|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:
# '''Services → Dnsmasq DNS & DHCP → General''': ''Enable'' und '''Listen Port''' <code>53053</code> (damit Dnsmasq nicht mit Unbound auf Port 53 kollidiert).
# Pro DHCP-Bereich eine eigene interne Domain verwenden, z. B. <code>lan.internal</code> für <code>192.168.1.0/24</code>.
# '''Services → Unbound DNS → Query Forwarding''' pro Bereich zwei Einträge anlegen:
{| class="wikitable"
! Domain !! Server IP !! Server Port
|-
| <code>lan.internal</code> || <code>127.0.0.1</code> || <code>53053</code>
|-
| <code>1.168.192.in-addr.arpa</code> (Rückwärtsauflösung) || <code>127.0.0.1</code> || <code>53053</code>
|}
Als interne Domain eignet sich <code>.internal</code>, die von der ICANN ausdrücklich für private Netze reserviert ist. Die Endung <code>.local</code> ist für mDNS (Bonjour/Avahi) vorgesehen und sollte nicht verwendet werden.

'''[[OPNsense - Kea DHCP mit Hochverfügbarkeit|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. <code>nas.example.internal</code> → <code>192.168.1.20</code> (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 <code>*</code> als Hostname entsteht ein Wildcard-Eintrag. Typischer Einsatz: '''Split DNS''' – ein öffentlicher Name wie <code>cloud.example.com</code> 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 <code>ad.example.internal</code> → 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. <code>10.168.192.in-addr.arpa</code>) 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.

{{Hinweis|Laut 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:
{| class="wikitable"
! Anbieter !! Server IP !! Port !! Verify CN
|-
| Quad9 || <code>9.9.9.9</code> / <code>149.112.112.112</code> || 853 || <code>dns.quad9.net</code>
|-
| Cloudflare || <code>1.1.1.1</code> / <code>1.0.0.1</code> || 853 || <code>cloudflare-dns.com</code>
|}
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 <code>0.0.0.0</code> 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 [[OPNsense - Q-Feeds Threat Intelligence|Q-Feeds]] seine Domain-Feeds direkt als Unbound-Blockliste registrieren.

{{Hinweis|Fü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 <code>use-application-dns.net</code> (per Override mit NXDOMAIN) die automatische DoH-Aktivierung.

=== Advanced-Optionen ===
{| class="wikitable"
! 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 [[OPNsense - WireGuard Site-to-Site und Road Warrior|WireGuard]] und [[OPNsense - OpenVPN Site-to-Site und Client-VPN|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 [[OPNsense - Wazuh-Agent|Wazuh-Agent]] auswerten.

== Typische Probleme und Lösungen ==
{| class="wikitable"
! 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 <code>127.0.0.1:53053</code> 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 <code>/usr/local/etc/unbound.opnsense.d/</code> 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 <code>nslookup</code> bzw. <code>dig</code> 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 [https://www.max-it.de/it-services/opnsense/ OPNsense-Firewall-Services von m.a.x. it] und einer [https://www.max-it.de/it-services/managed-firewall/ Managed Firewall von m.a.x. it].

== Siehe auch ==
* [[OPNsense - Kea DHCP mit Hochverfügbarkeit]]
* [[OPNsense - Dnsmasq DHCP-Server]]
* [[DNS]]
* [[DNSSEC]]
* [[DHCP]]
* [[OPNsense - Q-Feeds Threat Intelligence]]
* [[OPNsense - WireGuard Site-to-Site und Road Warrior]]
* [[OPNsense - Zenarmor Next-Generation-Firewall]]
* [[OPNsense - Eine kurze Einführung]]
* [[OPNsense - Plugin-Liste]]

== Links und Quellen ==
* [https://docs.opnsense.org/manual/unbound.html OPNsense-Doku – Unbound DNS]
* [https://docs.opnsense.org/manual/dnsmasq.html OPNsense-Doku – Dnsmasq DNS & DHCP (Zusammenspiel mit Unbound)]
* [https://nlnetlabs.nl/projects/unbound/about/ NLnet Labs – Unbound]
* [https://www.max-it.de/it-services/opnsense/ m.a.x. it – OPNsense-Firewall-Services]

{{Uebermax}}
[[Kategorie:IT-Security]]

OPNsense - Unbound DNS Resolver - Versionsgeschichte

imported>TechCorner-Redaktion: Verlinkung auf den Artikel OPNsense - Kea DHCP mit Hochverfügbarkeit ergänzt