Guten Morgen zusammen.
Der Titel sagt im Prinzip schon alles: Ich muss mich über Weihnachten endlich mit dem Ende von ISC DHCP beschäftigen, und das führt zwangsläufig zu Fragen im Zusammenhang mit DNSmasq. Je mehr ich lese, desto mehr "Meinungen" finde ich zu dem Thema. Nun frage ich mich:
- Gibt es da nur eine korrekte Konstellation, und die anderen Sachen funktionieren halt leidlich?
- Oder gibt es tatsächlich mehrere, richtige Setups?
Im Moment habe ich AdGuardHome als DNS-Server für die Clients. Dieser leitet 100% an Unbound weiter. Fertig. Lief so nun 2 Jahre einwandfrei.
Mich reitet die Frage, welcher Dienst nun der DNS-Server auf Port 53 sein soll in Zukunft? Und wie viel Unfug ich ineffizient ans Laufen bekomme, weil ich einer falschen Meinung im Internet gefolgt bin?
1) Client --> AGH --> extern: Unbound
|
--> intern: DNSmasqDas habe ich gerade testweise laufen. DNSmasq läuft auf Port 53000 und löst die lokale Domain auf mit folgendem Eintrag in AGH: [/zurhorst.baerl/]192.168.1.1:53000
2) Client --> DNSmasq --> AGH --> Unbound
3) Client --> DNSmasq --> AGH --> Unbound
|
--> Unbound (Fallback, falls AGH ausfällt)
4) Client --> DNSmasq --> AGH --> Provider-DNSAlle diese Varianten, wo ich den DNSmasq auf Port 53 setze, die habe ich bisher noch nicht angefasst.
Was ist denn nun richtig?
Danke & viele Grüße,
Marcus
Ich sehe zwei sinnvolle Setups:
- DNSmasq für alles (DHCP und DNS)
- Kea und Unbound
Beide potentiell kombiniert mit AdGuard Home.
Ich verwende Kea und Unbound mit AGH und das funktioniert prima. Ich registriere allerdings keine dynamischen Leases im DNS - das hatte ich auch mit ISC nicht getan. Statische Leases funktionieren prima.
Ich habe vor kurzem (vor/letzte? Woche) von ISC / unbound / AdGh umgestellt.
Nutze jetzt AdGh zusammen mit dnsmasq und unbound. Das funktioniert stabil.
AdGh leitet an unbound weiter. Dnsmasq macht DHCP und ist autoritativer DNS-Server für meine interne Domain. Anfragen dazu werden von unbound dorthin umgeleitet. Funktioniert im dnsmasq mit statischen Überschreibungen und auch mit dynamischen IPs.
Moin.
Zwei Antworten, zwei Meinungen. Also gibt es schon mehrere Möglichkeiten.
Ich stelle die Frage mal anders und versuche, über meine Requirements zu kommen.
- Ich hätte gerne Filterung der Werbung --> AGH wird benötigt
- Ich würde gerne meine Geräte daheim mit Namen ansprechen.
Beim zweiten Punkt bin ich flexibel.
Am liebsten würde ich das Gerät direkt mit "ping <hostname>" erreichen können. Alternativ wäre ein "ping <hostname>.zurhorst.baerl" für mich aber auch in Ordnung.
Damit stellt sich mir die Frage, ob ich Unbound wirklich dringend benötige, oder ob DNSmasq alleine die Anforderung erfüllen könnte.
Vermutlich nämlich nicht.
Dann wären zwei Wege:
1) Client --> DNSmasq --> AGH --> Provider-DNS
|
--> Provider-DNS (Fallback, falls AGH ausfällt)
2) Client --> AGH --> Provider-DNS
|
--> DNSmasq (nur für intern)
Das erste gefällt mir fast besser, weil ich damit noch mögliche Fehler im AGH überbrücken könnte.
Der Preis ist dann aber, dass ich keine einzelnen Statistiken mehr sehe im AGH, und dass ich nicht pro Gerät individuelle Regeln einrichten könnte.
In beiden Szenarien wäre aber mit Unbound ein Dienst raus.
Benutz doch die Blocklisten in Unbound und die Statistic darin. Sind erst azfgewertet worden in den letzten Updates.
AGH wird unter umständen gar nicht mehr benötigt.
AGH hat ein viel netteres User-Interface, was das Blocken und Ausnahmen angeht, das ist doch überhaupt nicht vergleichbar. Wann hast du dir das Dashboard von AGH zuletzt angesehen? Und dann gibt es Apps für Mobilgeräte, mit denen man das mal für 5 Minuten ausschalten kann, etc. pp.
Ich predige ja auch immer möglichst einfache Setups aber AGH ist eine völlig andere Liga.
Mein Missfallen hat nichts mit den Fähigkeiten oder Userinterface von AGH zu tun, es sind eher Umweltfaktoren wie das bauen der Binary und die Distribution (das schließt aber die Person aus die das Repo und das Plugin maintained, nichts gegen die. Es hat nichts mit ad hominem zu tun, es hat nur mit der Software und deren Herkunft und der Distribution zu tun die einfach mehr Supportaufwand bedeutet.)
Für das Ausmaß an Installationen gerade bei Home-Usern wäre eine andere (öffentliche) Build Methode und andere Distribution der Binary sicherlich besser, aber schwer umsetzbar.
EDIT: Bleh Artikulation ist schwer xD
Es gibt doch einen FreeBSD Port. Rein in die Poudriere und es fällt ein Paket raus. Was hält euch davon ab, das Plugin ins offizielle Community Repo zu nehmen?
Ich kann dazu nichts sagen weil ich es nicht weiß.
Wenn ich den computer nur mit "hostname" erreichen möchte statt "hostname.searchdomain", hätte dies dann einen Unterschied ob Unbound, AGH oder DNSmasq der DNS-Server auf Port 53 ist?
-- Davon würde ich erst mal gerne abhängig machen, was ich an die Clients verteile.
Quote from: mzurhorst on December 13, 2025, 02:42:01 PMWenn ich den computer nur mit "hostname" erreichen möchte statt "hostname.searchdomain", hätte dies dann einen Unterschied ob Unbound, AGH oder DNSmasq der DNS-Server auf Port 53 ist?
Nein, das passiert alles auf dem jeweiligen Client. Der DHCP-Server muss den Clients die Domain oder eine Liste von Domains mitgeben. Die Resolver-Library hängt die Domain dann an die Hostnamen an. Der DNS-Server verändert niemals die Anfragen, mit den der Client ihn bewirft.
Danke Patrick, das war mir nicht klar.
Dann werde ich DNSmasq nächstes Wochenende auf Port 53 setzen und von dort aus weiter zu AGH und fertig.
Bin gerade nicht zuhause.
Aber ich würde wirklich wetten, dass manchmal ein "ping opnsense" nicht klappt, ein "ping opnsense.zurhorst.baerl" hingegen schon.
Quote from: mzurhorst on December 13, 2025, 05:57:02 PMAber ich würde wirklich wetten, dass manchmal ein "ping opnsense" nicht klappt, ein "ping opnsense.zurhorst.baerl" hingegen schon.
Dann hat der Client "zurhorst.baerl" nicht als Domain konfiguriert.
Quote from: Patrick M. Hausen on December 13, 2025, 06:12:37 PMDann hat der Client "zurhorst.baerl" nicht als Domain konfiguriert.
Ja, danke. Genau das war das Problem. In einem der VLANs fehlte das im ISC DHCP. Das Problem hockt mal wieder vor dem Monitor. :-/
Quote from: Patrick M. Hausen on December 12, 2025, 10:22:53 AMIch verwende Kea und Unbound mit AGH und das funktioniert prima. Ich registriere allerdings keine dynamischen Leases im DNS - das hatte ich auch mit ISC nicht getan. Statische Leases funktionieren prima.
Hallo Patrick,
wärst Du bereit, Dein Setup zu teilen bzw. näher zu erläutern?
Ich habe zwar mit Dnsmasq, AGH und Unbound geliebäugelt, entnehme aber den Beiträgen, dass diese Variante nicht optimal ist!?
Ich möchte gerne ebenfalls Adguard Home behalten, weiterhin DNS over TLS einsetzen und benötige auch eine Namensauflösung sowie eine statische IP-Vergabe anhand von Mac-Adressen. Da ist dann wohl KEA DHCP ind Verbindung mit Unbound und AGH besser geeignet.
Ich habe aber zu wenig Wissen, um die Migration zu KEA SICHER umzusetzen...
Quote from: emmitt on August 31, 2026, 06:55:30 PMIch habe zwar mit Dnsmasq, AGH und Unbound geliebäugelt, entnehme aber den Beiträgen, dass diese Variante nicht optimal ist!?
Was du im Einzelfall nutzt ist im Prinzip völlig wurscht. Das ist lediglich ein "Komplexitätsding" mit "wie viele Dienste will man verschachteln". DNSmasq kann jetzt DHCP+DNS also wird's von OPNsense als default gerollt, weil es halt nur ein laufender Service ist. OK fein. Vorher war es eben ISC DHCP und Unbound oder DNSmasq als DNS. Das Gleiche kannst du jetzt wieder haben eben mit Kea als DHCP und Unbound (immer noch) für DNS. Das ist das erste Level der Entscheidung.
Dazu kommt allerdings: DNSmasq ist nur ein Forwarder - kein Resolver. Du brauchst also zwingend noch irgendwas wohin da DNS geballert wird. Viele nehmen public DNSe - ich persönlich mags gar nicht. Warum soll ich irgendeiner Shady Bude meinen kompletten Traffic (via DNS) verraten? Nur weils kostenlos ist? :)
Unbound ist ein Resolver, löst also über die DNS Roots auf. Es kann zwar im Forward Mode arbeiten, primär ists aber ein Resolver. DAS ist der große Unterschied zwischen Setups mit DNSmasq und Unbound. Forward vs Resolve. Resolver - hab ich an mehreren Stellen schon ausführlicher beschrieben - ist im Normalfall eben resilienter gegen Ausfälle an zentralen Stellen. Oh der Google DNS ist tot? Meh. Cloudflare mal wieder weg? Meh. Quad9 muss irgendwelche Seiten aus dem DNS werfen? Meh. Egal. Wenn du über die DNS Roots auflöst fragt dein Unbound immer die entsprechenden DNS Server der Domain direkt nach den Einträgen. Keine großen zentralen Brocken, die dann ggf. falsche/keine Antworten liefern (dürfen). Daher resilienter weil Ausfälle nicht so ins Gewicht fallen.
Und dann kommt eben noch das Filtering Thema dazu. Wie Cedrik schon sagt kann das Unbound in der Sense mit Blocklisten auch selbst, dann aber eben nicht so schön mit Log und einfachem entblocken und Zip und Zap wie eben ein Tool mit hübscher GUI wie nen AdGuard Home (oder PiHole bspw.). Wenn simples Blocking reicht -> Unbound + DNSBLs und gut. Wenns mehr sein darf + Statistiken und GUI und Co -> AGH.
Wenn die Entscheidungen durch sind, ist es nur noch ein Zusammmenstecken der Komponenten. Je nach Konfiguration kannst du dann AGH auf internem Interface auf 53 lauschen lassen, Unbound auf 5353 umziehen und dem AGH als Forward dann localhost:5353 verpassen damit er das an den internen Unbound weitergibt. Der macht dann die Endauflösung via Roots und Resolving. Wenns DNSmasq ist, gleiches Spiel. Das was die Clients bekommen/erreichen sollen, sollte auf Por 53 laufen, den Rest packt man auf andere Ports und forwarded da hin.
Kea ist da eigentlich DHCP-technisch völlig simpel und annähernd gleich mit ISC zu konfigurieren. Außer du hast große Sonderlocken mit irgendwelchen DHCP Optionen und Co., das könnte dann problematischer werden, aber für Standard run-of-the-mill normalen DHCP gibts da gar nicht viel zu failen.
DoT, DoH und Co. halt ich persönlich zwar für quark, aber das darf jeder für sich entscheiden :) Aber statische IP/mac/Namen sind in Kea jetzt keine RocketScience anzulegen.
Cheers :)
Quote from: JeGr on September 04, 2026, 01:01:33 PMAußer du hast große Sonderlocken mit irgendwelchen DHCP Optionen und Co., das könnte dann problematischer werden
Missed the memo? Kea in OPNsense ist mehr oder wenige feature complete im Vergleich mit ISC mit der einen Ausnahme: Registrierung dynamische Leases im DNS. Aber custom options funktionieren inzwischen, sogar flexibler als früher mit ISC.
Für dynamische leases in KEA haben wir auch eine Lösung, ist aber erst nur in der Business Edition:
https://docs.opnsense.org/vendor/deciso/opndns.html#dynamic-dns-with-kea-dhcp-rfc2136
Funktioniert super, hab ich bei mir daheim seit Monaten laufen (ist eins meiner Plugins)
Großartig! Das einzige Feature, das nur Heimanwender interessiert, ist exklusiv in der Business Edition 🙂
Nein, ernstfaft: klasse, dass da was weiter geht. Aber im Enterprise-Umfeld hat man meiner Erfahrung nach DHCP und DNS im Active Directory und fertig. Dieses Beharren darauf, dass man unbedingt Reverse-Auflösung für jedes dödelige Telefon braucht, kenne ich nur von Privatanwendern.
Danke. Ich bin mir dessen bewusst.
Trotzdem, ein Authoritativer DNS server der etwas "purer" und "strikter" ist als das Bind plugin, ist in vielen Fällen trotzdem recht nützlich.
Schon genug Kunden gehabt die z.b. die OPNsense mit einem WLAN Controller oder sowas verwendet haben der einen SRV und TXT record braucht für die provisionierung (ich weiß, interessant). Grundsäzlich gibt es zwar 90% AD oder BIND on premise, aber für kleinere Kunden ist ein eigenes Authoritives plugin was besser supported werden kann besser geeignet als z.B. das os-bind plugin.
Quote from: JeGr on September 04, 2026, 01:01:33 PMWenn die Entscheidungen durch sind, ist es nur noch ein Zusammmenstecken der Komponenten. Je nach Konfiguration kannst du dann AGH auf internem Interface auf 53 lauschen lassen, Unbound auf 5353 umziehen und dem AGH als Forward dann localhost:5353 verpassen damit er das an den internen Unbound weitergibt. Der macht dann die Endauflösung via Roots und Resolving. Wenns DNSmasq ist, gleiches Spiel. Das was die Clients bekommen/erreichen sollen, sollte auf Por 53 laufen, den Rest packt man auf andere Ports und forwarded da hin.
Kea ist da eigentlich DHCP-technisch völlig simpel und annähernd gleich mit ISC zu konfigurieren. Außer du hast große Sonderlocken mit irgendwelchen DHCP Optionen und Co., das könnte dann problematischer werden, aber für Standard run-of-the-mill normalen DHCP gibts da gar nicht viel zu failen.
Ganz herzichen Dank für Deine Mühe und die ausführliche Antwort JeGr!
Das hat mir sehr geholfen und ich habe es jetzt so umgesetzt: AGH -> Unbound -> KEA
Läuft prima!
Greetz Emmitt
QuoteWarum soll ich irgendeiner Shady Bude meinen kompletten Traffic (via DNS) verraten? Nur weils kostenlos ist? :)
Für business und extended setups, ok.
Aber ist da der dns im opnSense eh die richtige Lösung?
Für Heimanwender, die hängen doch meist am Tropf des ISP, der weiß eh alles. Da kann man auch dessen DNS Resolver verwenden, vorausgesetzt die funktionieren vernünftig? Mir ist bei meinem noch nichts böses aufgefallen (Filtering, Ausfälle und co).
Quote from: HBerger on September 10, 2026, 11:44:43 AMQuoteWarum soll ich irgendeiner Shady Bude meinen kompletten Traffic (via DNS) verraten? Nur weils kostenlos ist? :)
Für business und extended setups, ok.
Aber ist da der dns im opnSense eh die richtige Lösung?
Für Heimanwender, die hängen doch meist am Tropf des ISP, der weiß eh alles. Da kann man auch dessen DNS Resolver verwenden, vorausgesetzt die funktionieren vernünftig? Mir ist bei meinem noch nichts böses aufgefallen (Filtering, Ausfälle und co).
Das ist natürlich eine Ansichtssache. Ich sehe es so wie @JeGr. Man muss den Datensammlern nicht alle Daten bequem per Haus liefern. Der ISP soll mal schön die aufgerufenen IP's sammeln und reverse DNS abfragen, wenn er neugierig ist;-). Mal davon abgesehen fragt unbound brav die jeweiligen Root-DNS-Server an. Die ganzen Resolver dazwischen gehen damit leer aus. Ist also bestenfalls der ISP, der ein Gesamtbild frei Haus bekommt.
Quote from: HBerger on September 10, 2026, 11:44:43 AMQuoteWarum soll ich irgendeiner Shady Bude meinen kompletten Traffic (via DNS) verraten? Nur weils kostenlos ist? :)
Für business und extended setups, ok.
Aber ist da der dns im opnSense eh die richtige Lösung?
Für Heimanwender, die hängen doch meist am Tropf des ISP, der weiß eh alles. Da kann man auch dessen DNS Resolver verwenden, vorausgesetzt die funktionieren vernünftig? Mir ist bei meinem noch nichts böses aufgefallen (Filtering, Ausfälle und co).
Das hat ja jetzt nicht direkt was mit Business oder Extended Setups zu tun, oder? Ich sehe nur selbst hier und anderswo ständig Private/HomeLab Builds, die dann zum Ende hin alles via VPN %irgendwo% hin schicken damit ja alles verschlüsselt ist. Aber bringt es was, dem VPN Anbieter dann alle Daten - plus ggf. noch Geld - in den Rachen zu werfen? Das hängt eben ganz vom Schutzbedürfnis ab. Und wenn das nicht irgendwo bei "mission critical" bis "Ich bin Edward Snowden" liegt, dann ist der Provider für dich noch die Kleinste Hürde. DER ist nämlich zumindest aktuell und noch an die DSGvO und andere Spielregeln im Land gebunden und muss deinen Kram bzw. die IP Zuordnung wieder löschen. %HochObenSicherVPN% muss das nicht. Oder dir zumindest nicht verraten. Und sitzt meist auch nichtmal in Ländern, wo du sie irgendwo behelligen kannst.
Das ist der eine Knackpunkt. Der andere ist: DNS irgendwo hin zu packen, wo du keine Kontrolle drüber hast. Also 1.1.1.1, 8.8.8.8 und Co. Die mögen schnell sein, aber die können halt morgen Filtern, zensieren, etc. Nutzt du Unbound als Resolver und den Weg über die Roots wird Zensur schwerer. Klar, dein ISP könnte reingrätschen und Port 53 intercepten und umleiten. Das könnte man dann aber erkennen und entsprechen Gegenmaßnahmen ergreifen. Solange die aber - siehe oben - an geltendes Recht gebunden sind, wäre das eine verdammt heikle Sache, sich bei sowas erwischen zu lassen.
Das ist aber der Grund, warum ich DoT/DoH kritisch sehe. DoT kann man genauso einfach blocken wie normales DNS. DoH/DoQ löst kein wirkliches Problem außer den Provider auszuhebeln. Wenn wir aber RogueISP haben, dann kann der einfach die bekannten DoH/DoQ Gegenstellen blocken. Klar kann man dann einen suchen der geht aber dann sind wir auf einem Level, wo wie ich schon weiter oben beschrieben hatte eher dann ein Konstrukt wie DoHoT sinnvoll wäre. Also DoH (DNS via HTTPS) und das via TOR um im Traffic vom TOR Netz unter zu gehen. Dann ist nicht mehr einfach erkennbar, dass das DNS Calls sind. Aber da sind wir dann schon weitaus weiter oben auf der Gefährdungsskala als "ich brauche schnelles DNS" :)
Wenn man selbst die volle Kontrolle möchte, ist es eh am Sinnvollsten, sich intern und extern nen DNS aufzubauen mit Blocklistings und Co (also AGH oder PiHole hinstellen). Und vom externen kann man dann auch wieder via Unbound brav DNS Resolving machen. Den kann man dann auf der Sense als Fallback Forwarder angeben und notfalls auch nen VPN dahin tunneln wenn einem der ISP suspekte Sachen macht. Immer noch besser als gratis oder für 1,39€/mtl den ganzen Kram via Cloudflare, Alphabet oder sonstwen zu jockeln :)
Cheers
Cheers
Dazu kommt doch, dass wir uns in dieser Runde hier gerade innerhalb von Deutschland unterhalten, jedenfalls meistens. Hier ist immer noch ein Rechtsstaat und es gilt die DSGVO. Von welchen ISPs reden wir denn bitte schön?
Was glaubst du wie die Kacke am Dampfen ist, wenn Telekom oder Vodafone dabei erwischt werden, wie sie shady Zeug mit dem Verkehr ihrer ISP-Kunden machen ...
Haben die nicht mal Malware-Filter eingebaut, ohne zu fragen, und das gab einen ziemlichen Shitstorm? Jedenfalls ist "Security on net" bei der Telekom heute erhältlich und optional. Kann ja jedes halten wie sie möchten.
Quote from: Patrick M. Hausen on September 14, 2026, 06:07:26 PMDazu kommt doch, dass wir uns in dieser Runde hier gerade innerhalb von Deutschland unterhalten, jedenfalls meistens. Hier ist immer noch ein Rechtsstaat und es gilt die DSGVO. Von welchen ISPs reden wir denn bitte schön?
Was glaubst du wie die Kacke am Dampfen ist, wenn Telekom oder Vodafone dabei erwischt werden, wie sie shady Zeug mit dem Verkehr ihrer ISP-Kunden machen ...
Korrekt :)
QuoteHaben die nicht mal Malware-Filter eingebaut, ohne zu fragen, und das gab einen ziemlichen Shitstorm? Jedenfalls ist "Security on net" bei der Telekom heute erhältlich und optional. Kann ja jedes halten wie sie möchten.
Jein. Der eine der beiden hatte mal "versucht" DNS zu filtern und hat dafür eine ziemliche Klage als Brett aufs Maul bekommen. Der ANDERE der beiden war "so frei" und hat Kunden bei "DNS nicht gefunden" (NXDOMAIN) einfach seine eigene DrecksSuchmaschine untergejubelt und damit die DNS Antwort von "nicht vorhanden" auf "gibts -> bitte hier lang" verfälscht, was DNS Poisoning ist und noch dazu abgreifen von Daten (was hat mein Kunde da gesucht/eingegeben) etc. etc. - wofür sie auch aufs Brett und ne Klage bekommen haben.
Also gerade WEIL sie das schon versucht haben und krachend gescheitert sind, weiß man, dass aktuell bei uns wenigstens noch halbwegs unsere DSGvO und Rechtssprechung greift. Auch wenns diverse Kandidaten immer wieder aufs Neue versuchen (siehe Vorratsdatenspeicher, aber-denk-doch-wer-an-die-Kinder DNS Sperren und Co).