OPNsense 21.7 und entfallene "Custom options" bei Unbound DNS

Started by Marcel_75, August 02, 2021, 09:14:37 PM

Previous topic - Next topic
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:

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.
The fact that we live at the bottom of a deep gravity well, on the surface of a gas covered planet going around a nuclear fireball 90 million miles away and think this to be normal is obviously some indication of how skewed our perspective tends to be. (Douglas Adams)

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

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.
Deciso DEC750
People who think they know everything are a great annoyance to those of us who do. (Isaac Asimov)

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

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.
The fact that we live at the bottom of a deep gravity well, on the surface of a gas covered planet going around a nuclear fireball 90 million miles away and think this to be normal is obviously some indication of how skewed our perspective tends to be. (Douglas Adams)

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
Deciso DEC750
People who think they know everything are a great annoyance to those of us who do. (Isaac Asimov)

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.
The fact that we live at the bottom of a deep gravity well, on the surface of a gas covered planet going around a nuclear fireball 90 million miles away and think this to be normal is obviously some indication of how skewed our perspective tends to be. (Douglas Adams)

Quote from: pmhausen on August 02, 2021, 10:00:57 PM
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

Quote from: pmhausen on August 02, 2021, 10:00:57 PM
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.
kind regards
chemlud
____
"The price of reliability is the pursuit of the utmost simplicity."
C.A.R. Hoare

felix eichhorns premium katzenfutter mit der extraportion energie

A router is not a switch - A router is not a switch - A router is not a switch - A rou....

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


Grüsse
Franco

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?
The fact that we live at the bottom of a deep gravity well, on the surface of a gas covered planet going around a nuclear fireball 90 million miles away and think this to be normal is obviously some indication of how skewed our perspective tends to be. (Douglas Adams)

@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.
Deciso DEC750
People who think they know everything are a great annoyance to those of us who do. (Isaac Asimov)

Quote from: franco on August 02, 2021, 10:18:19 PM
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.