Opnsense from the scratch, welcher DHCP und DNS Server wird nun empfohlen.

[rubinho]

Moin Leute,

ich bin gerade dabei meine letzten beiden Pfsensen auf Opnsense zu migrieren.
Da ich nicht viel von der Pfsense Konfig übernehmen kann/will, werde ich die Opnsense quasi manuell einrichten.

Jetzt stehe ich aber wieder vor der Entscheidung, ISC oder Kea,bzw. Unbound, oder DNSMasq.

Da ich in den Pfsensen isc und unbound nutze, wäre der einfachste Weg, auch wieder auf diese Kombi zu setzen.
Allerdings möchte ich in einem Jahr (Spekulation) nicht alle statischen DHCP Einträge nochmal in KEA eintragen, weil ISC nun entgültig ausgedient hat.

Was mich an Kea momentan noch stört, ist die fehlende dynamische DNS Registration. Statische scheinen ja schon zu funktionieren. Allerdings nicht mit DNSMasq. (So meine Erfahrung)

Das Problem war 2023, als ich mit meiner primären Pfsense gewechselt bin, auch schon, allerdings war Kea da noch relativ frisch am Start und dachte es dauert noch ne Weile bis ISC ausgedient hat. Nun haben wir 2025 und das Thema ist leider immer noch nicht entschieden.

Von daher bin ich mir momentan nicht sicher, was der beste Weg ist.
Grundsätzlich kann ich aber sagen, dass es mir egal ist, welcher Dienst sich durchsetzt und ich am besten einsetzen soll. Es muss DNS Registrion funktionieren + die Standard Funktionen funktionieren.

Gibts da Empfehlungen, oder soll ich weiter auf die Kombi ISC/Unbound setzen?

VG
Rubinho

[Monviech (Cedrik)]

Das hier wird bald die empfohlene Kombination an Diensten. Doku ist noch WIP.

Dnsmasq mit DHCP gibt es schon in der neuesten Developement version glaub ich.

Ist aber noch nicht in Community.

https://github.com/opnsense/docs/blob/d860f3ade358adab598f7de467037f70dbc88098/source/manual/dnsmasq.rst#dns-and-dhcp-for-simple-networks

[RES217AIII]

Welche Gründe gibt es konkret, weshalb der Weg mit Kea nicht mehr weiterverfolgt wird?
Ist Kea ein totes Gleis und ich sollte mir langsam Gedanken zu  einer Umstellung der Dienste machen?
Im Moment bin ich bei einem einfachen Setup sehr zufrieden mit Kea, stabil und schnell.
Wie funktioniert eine Dienstekombination mit DNSMasq, Unbound und AdguardHome?

Viele Grüsse
Bernd

[Monviech (Cedrik)]

Der Weg mit Kea wird doch weiterverfolgt. Es ist der einzige open source supportete DHCP Server der richtiges HA kann mit Lease Synchronization.

DNSmasq ist halt einfach feiner für kleine Setups.

Ich benutze es daheim schon in der kombination wie oben in den docs beschrieben für die automatische DNS registrierung.

[rubinho]

Erstmal danke für die Info.

Ich hab mich gestern für den (vermeintlich) leichten Weg entschieden und die PFsense-Konfig meiner statischen DHCP Einträge und manuellen DNS Einträgen in die Opnsense Konfig mittels Notepad++ konvertiert. Hat mich 15min gekostet und meine Einträge waren drüben.

Da die investierte Zeit überschaubar und die neue Lösung ja noch nicht ogfiziell released ist, kann ich es verkraften, wenn ich in der nächsten Zeit nochmal Hand anlegen muss.

Ich werde mir mal eine DEV Version installieren und mir die neuen DNSmasq Optionen anschauen.

VG
Rubinho

[JeGr]

Nur mal als eine andere Meinung: ich sehe DNSmasq nicht als die "einfachste" oder auch sinnvollste Konfiguration. Da mag man je nachdem gern anderer Meinung sein :) Aber ich sehe es nicht als sinnvoll an, DNSmasq als Forwarder als Default zu nutzen wenn man einen vollwertigen Resolver nutzen kann. Ja mag "leicht" für Anfänger sein, da man nur einen Dienst braucht, DHCP ist gleich im DNS mit drin etc.

Aber die Anzahl meiner Clients in der Praxis, die wirklich ihren Namen im DNS brauchen ist verschwindend gering und meist sind das eh Geräte, die entweder (semi)statisch über Reservierung oder mit fixer IP im Netz sind. Normale Clients brauche ich seltenst als Name im DNS. DHCP Clients in DNS hatte ich schon lange keinen Bedarf mehr, aber natürlich YMMV.
Abgesehen von HA Themen weiß ich jetzt natürlich nicht, was das DNSmasq DHCP conf setup bieten will/wird, aber gerade in vielen Homelabs ist es nicht unüblich, dass mal in ein paar DHCP Segmenten/VLANs ein paar DHCP Optionen mehr ausgegeben werden müssen. Inwiefern das das neue Setup kann - keine Ahnung aber ich sehe da ISC/KEA  als sinnvoller, kann mich aber auch täuschen.

Wo meine Meinung aber stark abweicht ist DNSmasq als alleinigen DNS Forwarder zu haben. Forwarding gibt m.M.n. effektiv das DNS aus der Hand und zentralisiert einen DER Dienste, die von Grund auf dezentral sein sollten. Ich weiß, jetzt sind vielleicht schon einige kurz davor, in die Tasten zu hauen: man hat seine eigenen geprüften, getesteten, geliebten DNS Server, die garantiert safe, privat, non-logging und datensparsam sind. Und das dürfen sie auch gerne sein, dagegen argumentiere ich ja gar nicht. Und wenn ihr das möchtet, könnt ihr gern sämtlichen DNS Traffic verschlüsselt dorthin blasen. Aber DNS wurde dezentral gebaut um eben genau das eigentlich nicht zu tun. Unbound in Resolver Konfiguration mit aktivem DNSSEC ist hier m.E. die wesentlich bessere Antwort. Ja komplexer, gebe ich gern zu. Aber bei einem Forwarder kann ich ohne weiteres keinem DNSSEC glauben, da ich nur die Antwort vom Upstream bekomme - und der kann mir alles erzählen. Und selbst wenn ich 4 gute privacy DNSe als Upstream habe, kann man mir da trotzdem Streiche spielen. Oder deren Cache versaut sein. Oder sie werden eben wie Quad9 o.ä. einfach mal wieder verklagt und verdonnert, Antworten zu geben, die nicht korrekt sind. Einen Resolver kann man so einfach hier keine falsche Antwort unterjubeln, denn er fragt eben via DNS Roots, TLD Nameserver am Ende den SOA Server der Zone selbst. Und der muss die korrekte Antwort kennen. Direkt von der Quelle.

Das hat sein Problem in Bezug auf "aber dann sind meine DNS Queries mitlesbar". Ja korrekt, da geht dann genau leider der ganze Hau mit DoT, DoH, DoQ und wie sie alle heißen nicht. Das ist aber auch genau der Knackpunkt. Da wird nur der Transport zum Server abgesichert. Ab da ist auch wieder eh alles mitlesbar. Und wenn eben doch mal einer den Serverbetreiber verklagt und dieser das Log anmacht, ist da auch alles lesbar. Genau wie - sonst die Gegenargumentation gegen Resolver - der böse ISP mitlesen könnte. Korrekt, die könnten da theoretisch mitgrabbeln was man tut. Nur gibt es da sowas wie DSGvO und GDPR und solang noch niemand wieder die große Vorratsdatenspeichersau durchs Dorf treibt (die dann wieder in KA die Klatsche kassiert), macht das aus Volumensicht für keinen Provider Spaß sowas zu machen. Was es dann zur schlichten Vertrauensfrage macht: traue ich meinem Forwarder DNS mehr als dem ISP, dass er nicht mitliest. Oder auch ist mir die DNS Integrität wichtiger als dass ich potentiell vor der Welt verstecke, welche böse Website ich ansehen wollt :)
Oder ob ich bspw. ein so hohes Schutzbedürfnis habe/abdecken möchte, dass ich wirklich (sinnvoll) meinen DNS Traffic absolut geheimhalten will. Dann bringt aber auch ein Forwarder mit DoT oder DoH nicht viel, denn deren IPs sind bekannt und wenn ich schon so viel Schutzlevel habe, dann gehe ich ja schon fast intrinsisch von state-level Akteuren aus. Da müsste ich dann schon Geschütze wie DoHoT auffahren (DNS over HTTPS over TOR), denn nur dann wäre auch mein DNS Traffic als HTTPS in TOR getarnt und nicht zu mir direkt zurück verfolgbar (außer jemand sitzt auf den TOR nodes und liest mit ;) aber andere Diskussion).

Am Ende hatten wir die Situation mit Fails bei Forwardern leider schon mehr als einmal - sie ist also nicht theoretisch - dass ein großer Forwarder nicht sauber gespielt hat - egal ob falsche Antwort, nicht erreichbar o.ä. Oder dass man falsche DNSSEC Antworten vom Forward bekam die man selbst nicht verifizieren kann. Dagegen hatte man dann bei Setups die Unbound mit Resolving nutzen zu den Zeiten keine dieser Probleme. Dafür gibts da hin und wieder andere.

Daher finde ich, wenn man schon "from scratch" anfängt mit dem Thema OPNsense und sich dann um die Grunddienste kümmert und das neu aufbaut, sollte man da IMHO schon mal drüber nachdenken, wie man das Thema DNS handhaben möchte. Gerade wenn man da z.B. das Ganze noch um DNS Blocking ergänzen möchte (oder kommt da auch was für DNSmasq zusätzlich?) wäre Unbound wahrscheinlich zwar komplexer für den Start aber aus der Perspektive Security, Privacy und Co. die interessantere Bank. Und wer mit sowas wie OPNsense anfängt, für den sind diese Themen ja sicherlich nicht uninteressant ;) sonst würde man den ganzen Spaß ja nicht anfangen :)

Sollte jetzt kein "Überzeugungs"-Text sein, sondern lediglich zum Nachdenken anregen :)

Cheers

[Monviech (Cedrik)]

Schau doch mal kurz für 2 Minuten das recommended Setup an was in dem github link weiter oben steht.

Im zweiten Satz steht schon was Sache ist.

[Patrick M. Hausen]

@Monviech - hab alles gründlich gelesen und ganz ehrlich: not impressed. Ich werde nicht ernsthaft in Erwägung ziehen, AdGuard Home, DNSmasq und Unbound auf einer Box zu betreiben. Das wird lustig hier im Forum, das mit den Leuten zu debuggen mit 3 Servern in einer Kette.

Außerdem widerstrebt mir die Inflation an third-party Komponenten, wenn es etablierte Tools gibt. DNSmasq wurde erfunden, um das auf einen Raspberry Pi zu klatschen, den DHCP-Server des Provider-Routers (Fritzbox) auszuschalten und dann alles für ein einfaches Heimnetz in einer Schachtel zu haben. Dabei sollte man es auch belassen.

Kea unterstützt RFC 2136. BIND existiert. Das wäre eine solide standardkonforme Implementierung.

Liebe Grüße, ihr macht tolle Arbeit. Ich kann nur manche Architektur-Entscheidung nicht ganz nachvollziehen.
Patrick

[Monviech (Cedrik)]

Das Problem ist, dass es keine Eierlegende Wollmilchsau in dem Bereich gibt.

Dnsmasq (obwohl es kein rekursiver Forwarder ist) kommt schon sehr Nahe an das, was die meisten normalen Setups benötigen.

Es existiert schon sehr lange, hat eine weite Verbreitung und ist sehr stabil. DNS registrierung ist built in.

Man benötigt nur reine DNS Mechanismen um es zu nutzen, ohne Dynamische Updates an eine Zone zu senden oder Skripting zu betreiben.

[passeri]

Ich habe @JeGrs Kommentare gelesen und stimme als relativ normaler Nutzer, der kein Experte ist, grundsätzlich zu. Ich bin kürzlich mit Unbound auf Kea umgestiegen. Beides ist nicht schwierig. Ich sah keinen Grund, DNSmasq zu verwenden, brauche keine automatische Registrierung und kann Dinge nach Bedarf benennen. Mein Eindruck ist, dass mit dieser Kombination potenzielle Probleme einfacher sind und ich mehr Kontrolle habe.

(übersetzt)

[Patrick M. Hausen]

Registrierung ist in BIND und Kea auch drin. Dafür gibt es einen Standard. Weshalb will man mehr als ein Tool für ein und denselben Job, wenn diese Kombination doch rein technisch betrachtet - nicht im derzeitigen Stand der Integration in OPNsense - alles abdeckt, was einem bei DHCP und DNS jemals unterkommen kann? Inkl. authoritativem Server, Secondary, ...

Das Buch zum DNS heißt nicht umsonst "DNS & BIND" 😉

[opnboi]

Wo meine Meinung aber stark abweicht ist DNSmasq als alleinigen DNS Forwarder zu haben. Forwarding gibt m.M.n. effektiv das DNS aus der Hand und zentralisiert einen DER Dienste, die von Grund auf dezentral sein sollten. Ich weiß, jetzt sind vielleicht schon einige kurz davor, in die Tasten zu hauen: man hat seine eigenen geprüften, getesteten, geliebten DNS Server, die garantiert safe, privat, non-logging und datensparsam sind. Und das dürfen sie auch gerne sein, dagegen argumentiere ich ja gar nicht. Und wenn ihr das möchtet, könnt ihr gern sämtlichen DNS Traffic verschlüsselt dorthin blasen. Aber DNS wurde dezentral gebaut um eben genau das eigentlich nicht zu tun. Unbound in Resolver Konfiguration mit aktivem DNSSEC ist hier m.E. die wesentlich bessere Antwort. Ja komplexer, gebe ich gern zu. Aber bei einem Forwarder kann ich ohne weiteres keinem DNSSEC glauben, da ich nur die Antwort vom Upstream bekomme - und der kann mir alles erzählen. Und selbst wenn ich 4 gute privacy DNSe als Upstream habe, kann man mir da trotzdem Streiche spielen. Oder deren Cache versaut sein. Oder sie werden eben wie Quad9 o.ä. einfach mal wieder verklagt und verdonnert, Antworten zu geben, die nicht korrekt sind. Einen Resolver kann man so einfach hier keine falsche Antwort unterjubeln, denn er fragt eben via DNS Roots, TLD Nameserver am Ende den SOA Server der Zone selbst. Und der muss die korrekte Antwort kennen. Direkt von der Quelle.

Danke, dem gibt es nichts hinzuzufügen :)

[mooh]

Forwarding gibt m.M.n. effektiv das DNS aus der Hand und zentralisiert einen DER Dienste, die von Grund auf dezentral sein sollten.

Absolut, aber da das Internet auch nicht mehr aus vielen kleinen Webseiten besteht, sondern sozial genannten Medien, ist der Punkt leider zunehmend irrelevant.

[meyergru]

Also die Verkettung verschiedener Dienste finde ich auch nicht so toll, ich kaufe Patricks Argumente dagegen. Wenn dann noch jemand mit Adguard Home oder PiHole kommt, wird's vollkommen unmöglich.

Ich brauche aber schon DHCP-Reservierungen inklusive Namen, um VMs oder IoT-Geräte addressierbar zu bekommen - ich möchte da einfach nicht noch an einer weiteren Stelle (DNS) eingreifen. Im Grunde läuft das auf ein Tripel "MAC-IP-Name" hinaus, im Zweifel bei dynamischer Zuweisung auch nur die Möglichkeit, ein Gerät per Namen adressieren zu können, ohne, dass die IP vorab festgeschrieben wird.

Die aktuelle ISC DHCP + Unbound Kombination kann das (leider nur nach Restart, wenn neue Reservierungen hinzukommen).

Leider ist die Kea-Integration noch nicht so weit, ganz abgesehen von anderen Dingen, die zur Feature-Partity mit ISC DHCP noch fehlen.

Das alles wäre kein großes Problem, wenn es eine zentrale Stelle gäbe, wo die Eintragungen solcher Tripel gemacht würden - welchen DHCP oder DNS man dann dazu nimmt, könnte ja egal sein, wenn aus der GUI-Einstellung alle jeweiligen Konfigurationsdateien erzeugt würden. Ich musste mich zum Testen mit der Umschreibung der ISC DHCP-Reservierungen in die Kea-Reservierungen in der config.xml herumschlagen (wer Interesse hat, ich habe mir von ChatGPT ein XSLT dafür schreiben lassen).

So etwas wäre unnötig, wenn wenigstens die Konfiguration dieser Angaben unabhängig vom eingesetzten Dienst wäre. Das wäre m.E. interessant - auch, weil man dann unter den Tools frei wählen kann.

[Schoerch]

Ich stehe vor dem gleichen "Problem" mit meiner neuen OPNsense. Sie soll meine varaltete Umgebung mit Sohos UTM Home Use und OES DNS+DHCP endlich ablösen. Gleichzeitig will ich die Anzahl der Hardware/VMs und den Stromverbrauch reduzieren. Ich bekomme es aktuell nicht hin, das die Opensense meine bestehende Umgebung sauber übernehmen kann ohne das andere Funktion weiter funktionieren (u.a. NTP).

Die Argumente von Patrik und meyergu sind schlüssig und eigentlich das wie es funktionieren soll. Ein DNS Dienst mit eigenen lokalen Zonen der die ROOTs direkt fragt und ein DHCP der diese Zone für die ganzen lokalen DHCP Clients aktualisiert ist die primäre Basis. In den lokalen DNS Zonen muss ich alle festen Records (A, AAA, NS, CNAME, MX, TXT) einfach setzen können. Das vermisse ich einfach bei Unbound, DNSmask und KEA.

In der GUI müssen einheitliche Konfigurationsseiten für DNS Zonen und DHCP vollständig möglich sein, unabhängig vom verwendeten Produkt. Die ganzen Seiten sehen mir total unaufgeräumt und stellenweise unlogisch aus.

Die zusätzlichen Filterfunktionen aka AdGuard, PiHole sollten nur OnTop sein.