OPNsense 21.7 und entfallene "Custom options" bei Unbound DNS

[Marcel_75]

Hallo zusammen,

vllt. habt ihr ja einen Tipp für mich, wie ich mit folgender Situation umgehen soll – und zwar habe ich folgende Herausforderung:

In Services: Unbound DNS: General habe ich im Bereich "Custom options" folgende Einträge:

Code: [Select]

forward-zone:
name: „.“
forward-addr: 10.5.5.1@53530
Auf diesem Port 53530 'lauscht' BIND, d.h. unter Services: BIND: Configuration ist der Listen Port auf 53530 gesetzt. Und natürlich gibt es eine entsprechende Firewall-Regel.

Der Hintergrund war, dass es ursprünglich keine Blacklist/Blocklist für Unbound sondern nur für BIND gab, wenn ich mich recht entsinne …

Als DNS Forwarders ist im BIND dann noch mein Pi-Hole eingetragen.

Da mit dem neuen OPNsense 21.7 "Noble Nightingale" release ja nun die "Custom options" bei Unbound DNS endgültig entfallen, frage ich mich, ob mein Konstrukt dann so überhaupt noch arbeiten würde?

In der Update-Beschreibung gibt es noch den folgenden Hinweis:

Local override directory /usr/local/etc/unbound.opnsense.d exists.

Heißt das, in diesen Ordner soll ich eine Datei legen, die dann meine "Custom options" für Unbound DNS beinhalten? Und falls ja, wie genau muss diese Datei dann heißen, damit das funktioniert? Und 'überlebt' das dann auch Updates auf 21.7.1, 21.7.2 usw., oder muss ich das dann jedes mal neu anlegen?

Danke im voraus für Eure Unterstützung.

[Patrick M. Hausen]

Was Du da reinlegst und was auf .conf endet, wird automatisch provisioniert und überlebt auch ein OPNsense-Update. Bugs jetzt mal außen vor 

Code: [Select]

root@opnsense:/usr/local/etc/unbound.opnsense.d # cat README
OPNsense: automatically included unbound.conf configuration files
moved into chroot directory /var/unbound/etc on reconfigure.


[Marcel_75]

Ah ok – d.h., ich lege im Ordner /usr/local/etc/unbound.opnsense.d eine Datei custom-options.conf an, in der dann

Code: [Select]

forward-zone:
name: „.“
forward-addr: 10.5.5.1@53530
steht und das war es schon?

Muss ich dann noch irgend welche chmod/chown Besonderheiten für /usr/local/etc/unbound.opnsense.d/custom-options.conf beachten?

Denn es gab ja den Hinweis, dass diese 'custom options' bei Unbound DNS entfallen, weil die als 'unsicher' gelten – deshalb will ich da auf Nummer sicher gehen, dass auch die Zugriffsrechte korrekt sind.

Danke für weitere Erläuterung.

[Patrick M. Hausen]

Nein, leg die einfach als root an, mode 644 ist der Default.

Die sind nicht unsicher, weil sie jemand lesen könnte. So ein Freitext-Feld ist unsicher, weil man sich damit seinen Unbound kaputt schießen kann. Schreib "blablubb" in die Custom Options und Dein DNS ist weg.

Das ist ein Feature, damit könnten sich Anwender ins Knie schießen. Also machen wir's weg - und bauen einen Mechanismus ein, damit Leute, die wirklich wissen, was sie tun, das weiter benutzen können. Braucht dann halt ssh und vi ...

Gruß
Patrick

[Marcel_75]

Ah ok, jetzt hab ich's kapiert. 

Danke!

Na dann warte ich mal noch den 21.7.1 release ab und dann wage ich das Upgrade.

[franco]

Die sind nicht unsicher, weil sie jemand lesen könnte. So ein Freitext-Feld ist unsicher, weil man sich damit seinen Unbound kaputt schießen kann. Schreib "blablubb" in die Custom Options und Dein DNS ist weg.

Das ist ein Feature, damit könnten sich Anwender ins Knie schießen. Also machen wir's weg - und bauen einen Mechanismus ein, damit Leute, die wirklich wissen, was sie tun, das weiter benutzen können. Braucht dann halt ssh und vi ...

Alles korrekt. Ich werde bald arbeitslos


<3

[chemlud]

Nein, leg die einfach als root an, mode 644 ist der Default.

Die sind nicht unsicher, weil sie jemand lesen könnte. So ein Freitext-Feld ist unsicher, weil man sich damit seinen Unbound kaputt schießen kann. Schreib "blablubb" in die Custom Options und Dein DNS ist weg.

Das ist ein Feature, damit könnten sich Anwender ins Knie schießen. Also machen wir's weg - und bauen einen Mechanismus ein, damit Leute, die wirklich wissen, was sie tun, das weiter benutzen können. Braucht dann halt ssh und vi ...

Gruß
Patrick

An einem kaputten DNS ist noch niemand gestorben, v.a. nicht auf dem "Einsteigerlevel", das hier ausgesperrt wird. Wenn man alle möglichen Plugins (bis hin zu proprietären) zulässt ist es leicht over the top, Anwender "vor sich selbst zu schützen". Vor allem wenn man dafür das (geniale!) Prinzip opfert, dass alle individuellen Anpassungen in EINER config.xml stehen.

Ich kauf die Argumentation nicht und bin nicht alleine damit. Aber ich hab keine Idee, was da wirklich dahinter steckt...

Muss jetzt aber nicht hier diskutiert werden.

[franco]

Mehr Feature Requests auf GitHub, mehr Diskussionen im Forum.. mittelfristig bis langfristig eine bessere Unbound Integration dadurch.


Grüsse
Franco

[Marcel_75]

Hallo zusammen,

eine Frage hätte ich dann doch noch einmal zu meinem "Konstrukt":

Unter System: Settings: General habe ich ja gar keine "DNS servers" hinterlegt, auch die "DNS server options" sind dort komplett deaktiviert.

Nun frage ich mich gerade, ob ich nicht auch "nur BIND" nutzen könnte, ohne im Unbound DNS erst noch darauf umzuleiten?

Oder ist mein "Konstrukt" (siehe erstes Posting in diesem Thread) schon ok so und anders geht das gar nicht?

[Patrick M. Hausen]

@Marcel_75 was Du verlierst, wenn Du Unbound deaktivierst und nur BIND nimmst, ist die Integration mit dem dhcpd, also dynamische Einträge im DNS. Zumindest beim jetzigen Stand der OPNsense.

D.h. Du musst alles, was Du lokal in einer Zone haben willst, auch selbst anlegen. Ich mache das so, denn ich mag es nicht, wenn beliebige DHCP-Clients mir meine Zone vollmüllen. Das muss aber jeder selbst entscheiden.

Ich hab auf allen Interfaces bis auf eines, aber zusätzlich localhost, den BIND. Das ist der Standard-Nameserver hier mit allen lokalen Zonen und einigen secondary/slave Zonen aus meiner Firma. In dem VLAN mit dem Famililennetzwerk lauscht auf Port 53 statt BIND der AdGuard Home. Und der forwarded dann an 127.0.0.1:53, also wieder BIND.

Läuft gut. Unbound vermisse ich nicht.

[Andreas_]

Mehr Feature Requests auf GitHub, mehr Diskussionen im Forum.. mittelfristig bis langfristig eine bessere Unbound Integration dadurch.


Grüsse
Franco

Ich verstehe den Ansatz, allerdings sind in Unbound allerhand recht exotische Optionen möglich die nicht nur ausgesprochen mühsam komplett umzusetzen sind, sondern auch für den Allerweltsuser die Angelegenheit sehr unübersichtlich machen würde. Die Extraoptionen sind zudem so speziell, dass ein Einzeilen-Hilfetext nicht ausreicht, da muss man schon die richtige Unbound-Doku lesen.
Der häufigste Fallstrick beim custom-Feld war sicher die Notwendigkeit, die Section "server:" mitschreiben zu müssen, das wäre doch im Hilfetext klärbar.