OPNsense + Unbound: Ein DNS-Server fürs ganze Netz

Kurz gesagt: Unbound ist auf jeder OPNsense schon an Bord — unter Services → Unbound DNS aktivierst du ihn, lässt Query Forwarding leer und schaltest DNSSEC sowie Register DHCP leases ein. Damit löst deine Firewall alle DNS-Anfragen selbst rekursiv auf, statt sie an Provider oder Google weiterzureichen — inklusive interner Hostnamen und auf Wunsch mit Blocklisten.

Wer nach der OPNsense-Grundkonfiguration den DNS-Punkt nur abgehakt hat, verschenkt eines der besten Features der Firewall: Unbound ist ein vollwertiger, validierender, rekursiver DNS-Resolver — dasselbe Stück Software, das viele auf einem Raspberry Pi neben Pi-hole betreiben, nur bereits integriert. Dieser Guide zeigt die saubere Einrichtung fürs ganze Netz.

Warum Rekursion statt Weiterleitung an den Provider? #

Weil beim Forwarding ein einziger Dritter deine komplette DNS-Historie sieht — beim rekursiven Auflösen nicht. Ein Forwarder (Provider-DNS, 8.8.8.8, 1.1.1.1) beantwortet jede Anfrage komplett: Er weiß, welche Domains dein Netz wann aufruft. Ein rekursiver Resolver fragt stattdessen selbst die DNS-Hierarchie ab: Root-Server („wer ist für .de zuständig?“), dann TLD-Server, dann den autoritativen Server der Domain. Jeder sieht nur seinen Ausschnitt, keiner das Gesamtbild.

Dazu kommt: Unbound validiert DNSSEC selbst, statt der Validierung eines Dritten vertrauen zu müssen, und cached aggressiv. Der Preis ist eine minimal langsamere Erstauflösung — dazu unten mehr.

Grundeinrichtung: Unbound in der Weboberfläche aktivieren #

Die komplette Grundeinrichtung passiert unter Services → Unbound DNS → General — mehr als eine Handvoll Haken braucht es nicht:

• Enable aktivieren (auf frischen Installationen meist schon gesetzt)
• Listen Port auf 53 lassen
• Network Interfaces: die internen Interfaces auswählen (LAN und deine VLANs) — nicht „All“, und vor allem nicht das WAN. Unbound soll nur deinem Netz antworten.
• DNSSEC aktivieren
• Register DHCP leases und Register DHCP static mappings aktivieren: Damit sind Geräte, die per DHCP eine Adresse bekommen, unter ihrem Hostnamen auflösbar — ping nas statt IP-Raten.
• Unter Query Forwarding nichts eintragen und sicherstellen, dass kein Haken bei „Use System Nameservers“ gesetzt ist. Genau das macht Unbound zum rekursiven Resolver.

Speichern, fertig. Im DHCP (Services → DHCPv4) verteilst du als DNS-Server die OPNsense-IP des jeweiligen Netzes — nach der Grundkonfiguration ist das ohnehin der Standard. Testen kannst du von einem Client aus mit nslookup labkompass.de oder dig labkompass.de — als Server sollte deine OPNsense antworten.

DNS over TLS: die Forwarding-Alternative #

Wenn du doch weiterleiten willst oder musst, dann wenigstens verschlüsselt — das kann Unbound unter Services → Unbound DNS → DNS over TLS. Dort trägst du Server ein, die DoT sprechen (Port 853), und Unbound reicht Anfragen verschlüsselt dorthin weiter, statt sie im Klartext über die Leitung zu schicken.

Sinnvoll ist das in zwei Fällen: wenn dein Provider Port 53 nach außen umbiegt oder filtert (Rekursion also gar nicht sauber funktioniert), oder wenn du bewusst einen Filter-Anbieter nutzen willst. Klar sein muss dabei: Der DoT-Anbieter sieht dann wieder deine gesamte DNS-Historie — verschlüsselt ist nur der Transportweg. Rekursion und DoT-Forwarding schließen sich aus; entscheide dich pro Setup für eines.

Host und Domain Overrides: interne Namen sauber auflösen #

Overrides sind der Grund, warum Unbound auf der Firewall so praktisch ist: Du definierst DNS-Antworten, die nur in deinem Netz gelten. Unter Services → Unbound DNS → Overrides gibt es zwei Werkzeuge:

• Host Overrides: ein Name → eine IP. nas.heim.lan → 192.168.10.20, proxmox.heim.lan → 192.168.10.10. Interne Dienste bekommen sprechende Namen, unabhängig von DHCP. Auch der klassische Reverse-Proxy-Trick läuft darüber: *.heim.lan-Einträge zeigen intern direkt auf den Proxy.
• Domain Overrides: eine ganze Domain → ein anderer DNS-Server. Nützlich, wenn z. B. hinter einem Site-to-Site-VPN ein eigener DNS-Server für firma.intern steht — Unbound leitet nur diese Domain dorthin, alles andere löst er weiter selbst auf.

Für die interne Domain gilt: keine erfundene öffentliche TLD nehmen, sondern eine Domain, die dir gehört (Subdomain reicht), oder klassisch etwas wie .lan bzw. .internal.

Zusammenspiel mit Pi-hole: solo oder in der Kette? #

Beides funktioniert — die Frage ist, wie viel Komfort du beim Filtern willst. Die zwei üblichen Architekturen:

1. Unbound solo auf der OPNsense: Ein Gerät weniger, ein Ausfallpunkt weniger. Blocklisten übernimmt das DNSBL-Feature (nächster Abschnitt).
2. Pi-hole vor Unbound: Der DHCP verteilt die Pi-hole-IP als DNS, und im Pi-hole trägst du unter Settings → DNS die OPNsense als einzigen Custom-Upstream ein. Pi-hole filtert mit seinem starken Dashboard und Pro-Client-Statistiken, Unbound löst rekursiv auf — die gleiche Kette wie in unserem Pi-hole+Unbound-Guide, nur dass der Resolver hier auf der Firewall läuft statt auf demselben Pi.

Wichtig in Variante 2: Register DHCP leases bleibt auf der OPNsense aktiv, damit der Pi-hole interne Hostnamen über seinen Upstream auflösen kann — und der DHCP darf die OPNsense nicht zusätzlich als zweiten DNS-Server ausliefern, sonst laufen Anfragen am Filter vorbei.

Blocklisten direkt in Unbound: das DNSBL-Feature #

Werbe- und Trackerfilterung geht auch ganz ohne Pi-hole: Unter Services → Unbound DNS → Blocklist aktivierst du DNSBL, wählst aus den mitgelieferten Listen aus (oder trägst eigene URLs ein) und Unbound beantwortet Anfragen an gelistete Domains schlicht nicht mehr sinnvoll. Whitelisting einzelner Domains ist dort ebenfalls möglich.

Ehrliche Einordnung: Funktional blockt das genauso wie ein Pi-hole — was fehlt, sind das Dashboard, die Query-Logs pro Client und der Ein-Klick-Whitelist-Workflow, wenn die Familie meldet, dass ein Shop-Link nicht mehr funktioniert. Fürs Erste ist DNSBL aber der einfachste Einstieg in netzweite Filterung: zwei Klicks, kein zusätzliches Gerät.

Typische Stolperfallen #

• Port 53 ist schon belegt: Unbound startet nicht, wenn auf der OPNsense noch Dnsmasq als DNS aktiv ist — es kann nur einer auf Port 53 lauschen. Unter Services → Dnsmasq DNS deaktivieren bzw. prüfen, dass nur ein Dienst den Port beansprucht.
• Hostnamen tauchen nicht auf: Register DHCP leases wirkt erst, nachdem Geräte ihre Lease erneuert haben — und nur für Geräte, die beim DHCP-Request überhaupt einen Hostnamen mitsenden. Für Infrastruktur sind statische Zuweisungen mit sauberen Namen ohnehin der bessere Weg.
• Erste Auflösung fühlt sich langsam an: Erwartbares Verhalten, kein Bug. Eine unbekannte Domain kostet mehrere Nachfragen durch die DNS-Hierarchie; danach kommt sie aus dem Cache. Nach der Aufwärmphase merkst du im Alltag nichts mehr davon.
• Clients umgehen deinen DNS: Geräte mit fest eingetragenem 8.8.8.8 fragen an Unbound vorbei. Wenn dich das stört: eine Firewall-Regel, die ausgehendes Port-53-Traffic auf die OPNsense umleitet oder blockt — ein eigenes kleines Projekt.
• Es klemmt trotzdem? Die OPNsense-Doku beschreibt jede Unbound-Option im Detail, und Services → Unbound DNS → Log File zeigt, was der Resolver tatsächlich tut.

Fazit #

Unbound auf der OPNsense ist der seltene Fall, in dem die beste Lösung schon eingebaut ist: fünf Haken in der Weboberfläche, und dein Netz löst DNS selbst auf — mit DNSSEC, lokalen Hostnamen und ohne DNS-Historie bei Dritten. Ob du darüber noch einen Pi-hole setzt oder mit DNSBL direkt auf der Firewall filterst, ist dann Geschmackssache — die solide Basis ist in beiden Fällen dieselbe.