lokale Namensauflösung funktioniert nicht (Unbound DNS und BIND)

Started by Marcel_75, August 11, 2020, 01:20:08 PM

Previous topic - Next topic
Hallo zusammen,

ich versuche mich mal an diesen Empfehlungen zu orientieren:

https://forum.opnsense.org/index.php?topic=12697.0

Folgender Fehler tritt auf: Die lokale Namens-Auflösung funktioniert nur, wenn auch mein Pi-hole als DNS-Server eingetragen ist, nicht jedoch wenn ich die OPNsense als alleinigen DNS-Server definiere.

Aufgefallen ist mir das leider erst jetzt bei einer manuellen Netzwerkeinstellung, denn per DHCP werden am Client als DNS-Server 10.89.89.11 (mein Pi-hole) und 10.5.5.1 (meine OPNsense) eingetragen (und damit funktioniert es wie gesagt auch).

D.h., wenn ich die Netzwerkeinstellungen per DHCP empfange, kann ich z.B. meinen iMac lokal auflösen (denn im Pi-hole sind diese als "Local DNS Records" eingetragen, siehe Screenshot "pi-hole-local-dns-records.gif"):

nslookup imac.localdomain
Server: 10.89.89.11
Address: 10.89.89.11#53
Name: imac.localdomain
Address: 10.5.5.199


Auch die Rückwärtsauflösung klappt problemlos:

nslookup 10.5.5.199
Server: 10.89.89.11
Address: 10.89.89.11#53
199.5.5.10.in-addr.arpa name = imac.localdomain.


Wenn als DNS-Server bei einer manuellen Netzwerkeinstellung jedoch ausschließlich meine OPNsense (10.5.5.1) als DNS-Server eingetragen ist, klappt es leider nicht:

nslookup imac
Server: 10.5.5.1
Address: 10.5.5.1#53
** server can't find imac: NXDOMAIN

nslookup imac.localdomain
Server: 10.5.5.1
Address: 10.5.5.1#53
** server can't find imac.localdomain: NXDOMAIN

nslookup 10.5.5.199     
Server: 10.5.5.1
Address: 10.5.5.1#53
** server can't find 199.5.5.10.in-addr.arpa: NXDOMAIN


In Services / Unbound DNS / Overrides ist natürlich ein entsprechender Eintrag vorhanden (siehe Screenshot "OPNsense-Unbound-Overrides.png").

Da ich auch BIND mit DNSBL nutze, steht in den "Custom options" unter Services / Unbound DNS / General folgendes:

forward-zone:
name: ,,."
forward-addr: 127.0.0.1@53530


D.h., den bis vor kurzem dort noch vorhandenen Eintrag

do-not-query-localhost: no

habe ich entfernt, aufgrund dieses Hinweises (ganz unten im Bereich "Advanced"):

https://docs.opnsense.org/manual/how-tos/bind.html

Aber vermutlich habe ich das einfach noch nicht korrekt verstanden und umgesetzt?

Anbei auch mein Netzwerkplan als Grafik (netzaufbau-double-nat.gif).

Danke vielmals 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)

Frage 1: wer ist den forwarder für wen?
Frage 2: welcher DNS hält die lokalen DNS-Einträge?
Frage 3: hast Du mal die Reihenfolge (im dhcp) der dns-Server umgedreht und dann getestet?
---
Regards
Rainer

Noch ne Frage: welchen Grund hat es, das Du den pihole vor der opnsense an der fritzbox betrteibst?
---
Regards
Rainer

Quote from: hopper on August 11, 2020, 01:57:18 PM
Noch ne Frage: welchen Grund hat es, das Du den pihole vor der opnsense an der fritzbox betrteibst?

Das hatte ganz einfach den Grund, dass auch Gäste in den Genuss eines Werbe- und Tracking-Blockers kommen sollten, aber ohne Zugriff auf mein 10.5.5.0/24-Netzwerk und vor allem die damit verbundenen Geräte.

D.h., Gäste bekommen Wi-Fi nur von der Fritzbox und sind somit im 10.89.89.0/24-Netzwerk, DNS macht dort ausschließlich der Pi-hole mit der 10.89.89.11.
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: hopper on August 11, 2020, 01:51:50 PM
Frage 1: wer ist den forwarder für wen?
Frage 2: welcher DNS hält die lokalen DNS-Einträge?
Frage 3: hast Du mal die Reihenfolge (im dhcp) der dns-Server umgedreht und dann getestet?

Frage 1: Wo/wie kann ich das prüfen? Bin leider kein Netzwerk-Experte ... Danke für präzisere Erläuterung der Frage.

Frage 2: Wie schon eingangs beschrieben sowohl der Pi-hole (durch manuell hinzugefügte "Local DNS Records"), als auch die OPNsense (durch manuell hinzugefügte "Overrides" Einträge im Unbound DNS).

Frage 3: Das habe ich noch nicht gemacht.

Mag zwar sein, dass er so dann erst bei der OPNsense gucken würde, dort nichts findet und dann auf dem Pi-hole schaut und die entsprechenden "Treffer" liefert ...

Aber das ist ja nicht mein Ziel!

Ich möchte, dass die lokale DNS-Auflösung auch komplett ohne Pi-hole funktioniert und korrekte Werte zurückliefert.

Also mit meiner Unbound DNS + BIND Variante.

Ergänzung: Ich habe die Reihenfolge zum Test jetzt mal kurz umgedreht, sprich 10.5.5.1 (OPNsense) als 1. DNS und 10.89.89.11 (Pi-hole) als 2. DNS eingetragen. Da kommt es genauso zum Abbruch, als wenn nur 10.5.5.1 (OPNsense) drin stehen würde, d.h. es wird leider gar nicht erst versucht, noch zusätzlich auf der 10.89.89.11 (Pi-hole) zu schauen.

Nur wenn ich die Reihenfolge so lasse, also 10.89.89.11 (Pi-hole) als 1. DNS und 10.5.5.1 (OPNsense) als 2. DNS, bekomme ich die gewünschten Ergebnisse der lokalen DNS Auflösung.
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)

So, nun ich wieder  ;D :

zu Frage 1:
Wie sind die Systeme "kaskadiert" - d.h. wen fragt der pihole als übergeordneten DNS und wen fragt die opnsense als übergeordneten DNS?
Wenn du also den pihole immer als primären DNS haben möchtest, muß dieser die fritzbox als primäfren DNS nutzen. Die opnsense nun muß wiederrum den pihole als DNS eingetragen haben.
Dann sollte die opnsense bei Anfragen, die sie ncht selber beantworten kann, den pihole fragen und der leitet die Anfrage dann an die fritzbox weiter, wenn er auch keine Informationen zu der Anfrage hat.

Ich hoffe, ich konnt meine Frage etwas mit den Ausführungen bessser formulieren.

zu Frage 2:
vom Sicherheitssapekt sicher ok. Das unangenehme an Deiner Config ist, das Du an zwei Stellen lokale Einträge pflegen mußt.

zu Frage 3:
Eine Sache habe ich vorhin überlesen - sorry: Du nutzt unbound und bind gleichzeitig? Beide Dienste lauschen auf dem gleichen Port (TCP 53) Kann es sein, das keiner von beiden sauber läuft?
Das würde erklären, warum die opnsens so gar nicht auf DNS-Anfragen reagiert, was Deine Tests ja zeigen. Ich denke, Deine lokale Auflösung kommt rein vom pihole - kann das sein?

Deaktiviere doch mal zum testen den bind und versuche dann eine DNS-Anfrage gegen die opnsense. im unbounf hast Du auch die Möglichkeit, unter "Blacklists" eine ähnliche Funktionalität des pihols zu implementieren.

Und noch eine Idee: sind Deine Netze in den Access Lists des unbound eingetragen? Wenn nicht, nimmt dieser keine Anfragen an.
---
Regards
Rainer

Mmh, das hätte ich vllt. extra erwähnen sollen:

Die DNS-Auflösung "nach draußen" funktioniert eigentlich in der OPNsense, Unbound DNS auf Port 53 und BIND ist zusätzlich auf Port 53530 für DNSBL vorgesehen (also als DNS blacklist, eine Art Pi-hole Ersatz mit verschiedenen Blocklisten).

dig @10.5.5.1 -p 53 heise.de

; <<>> DiG 9.10.6 <<>> @10.5.5.1 -p 53 heise.de
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34533
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;heise.de. IN A

;; ANSWER SECTION:
heise.de. 6397 IN A 193.99.144.80

;; Query time: 30 msec
;; SERVER: 10.5.5.1#53(10.5.5.1)
;; WHEN: Tue Aug 11 17:25:42 CEST 2020
;; MSG SIZE  rcvd: 53


sowie

dig @10.89.89.11 -p 53 heise.de

; <<>> DiG 9.10.6 <<>> @10.89.89.11 -p 53 heise.de
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28930
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;heise.de. IN A

;; ANSWER SECTION:
heise.de. 16376 IN A 193.99.144.80

;; Query time: 30 msec
;; SERVER: 10.89.89.11#53(10.89.89.11)
;; WHEN: Tue Aug 11 17:26:05 CEST 2020
;; MSG SIZE  rcvd: 53


funktionieren also.

Was mir jedoch auffällt – auf Port 53530 klappt das so nicht ...

dig @10.5.5.1 -p 53530 heise.de

; <<>> DiG 9.10.6 <<>> @10.5.5.1 -p 53530 heise.de
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached


Wobei das aber mal funktioniert hatte, soll heißen, die Domains die mit Hilfe der DNSBL Blocklisten blockiert werden, wurden eigentlich blockiert (und auch zusätzliche Sonderfunktionen wie z.B. "Enable Google SafeSearch", "Enable DuckDuckGo SafeSearch", "Enable Youtube Adult Restrictions" und "Enable Strict Bing Search" waren aktiv und konnten nicht umgangen werden).

Korrektur: Habe das gerade noch einmal getestet – also den Pi-hole aus gemacht – das "blocking" dank der DNSBL klappt. Nur die Abfrage per dig auf Port 53530 nicht, da das dann "intern" in der OPNsense gemacht wird.

D.h., außen fragt er natürlich nur auf DNS Port 53, intern gibt es dann noch die "custom option" im Unbound DNS per

forward-addr: 127.0.0.1@53530

(siehe auch mein Eingangs-Post, da habe ich dies ja schon erwähnt)
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)

Ich glaube nach wie vor, der entscheidende Punkt ist bei den "Custom options" von Unbound DNS versteckt:

https://docs.opnsense.org/manual/how-tos/bind.html

Anbei auch noch einmal ein Screenshot, damit ihr besser versteht wovon ich rede (Unbound_DNS_Custom_Options.png).

Es gibt übrigens schon seit einigen OPNsense-Versionen folgenden Hinweis bei den "Custom options" von Unbound DNS: "This option will be removed in the future due to being insecure by nature. In the mean time only full administrators are allowed to change this setting".

Aktuell ist als "Listen IPs" bei mir in Services / BIND / Configuration noch die 127.0.0.1 eingetragen (was ja der localhost wäre, richtig?).

Wenn ich die Anmerkung (siehe Screenshot) richtig verstehe, soll ich unter "Listen IPs" in Services / BIND / Configuration statt der 127.0.0.1 meine "LAN IP" eintragen, das wäre in meinem Fall dann also die 10.5.5.1 meiner OPNsense?

Und in den "Custom options" unter Services / Unbound DNS / General sollte dann statt

do-not-query-localhost: no
forward-zone:
name: ,,."
forward-addr: 127.0.0.1@53530


noch noch folgendes stehen:

forward-zone:
name: ,,."
forward-addr: 10.5.5.1@53530


Sonst hätten meine "Host Overrides"-Einträge unter Services / Unbound DNS / Overrides keine Funktion?

Oder missverstehe ich das immer noch?

Danke für weitere Hilfe!
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)

Habe das jetzt mal wie beschrieben angepasst (also statt der 127.0.0.1 nutze ich jetzt die 10.5.5.1 bei BIND).

Dann funktioniert DNS aber gar nicht mehr ...

Deshalb habe ich das jetzt doch wieder auf 127.0.0.1 gestellt.

Also entweder missverstehe ich diese Hinweise völlig, oder aber das funktioniert so mit der aktuellen OPNsense 20.7 gar nicht mehr?

Wer kann helfen?
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: hopper on August 12, 2020, 09:30:30 AM
Versuchs mal mit TCP an Stelle von UDP

Hallo Rainer,

an welcher Stelle genau meinst Du?

Muss jetzt leider erst mal los und kann mir das erst abends ansehen ...

Danke & beste Grüße,
Marcel
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)

Du hast in Deinem Screenshot ipV4 und V6 auf udp stehen - DNS möchte gerne auf UDP und TCP hören - das könnte es sein
---
Regards
Rainer

Das ändert leider nichts, auch wenn TCP/UDP auf Port 53 und 53530 erlaubt ist.

Es hätte mich ehrlich gesagt auch gewundert – denn grundsätzlich klappte DNS ja schon, wenn nur UDP auf Port 53 und 53530 erlaubt war.
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: Marcel_75 on August 12, 2020, 02:17:49 PM
Das ändert leider nichts, auch wenn TCP/UDP auf Port 53 und 53530 erlaubt ist.
Schade....
---
Regards
Rainer

Aber ich lasse das trotzdem mal auf TCP/UDP stehen, denn dazu habe ich das hier gefunden:

https://www.infoblox.com/dns-security-resource-center/dns-security-faq/is-dns-tcp-or-udp-port-53/

War also grundsätzlich ein guter Hinweis.

Bin trotzdem mal gespannt, wie das Problem letztlich zu lösen ist. Die erfahreneren Leute aus diesem Forum sind glaube ich aktuell alle noch in ihrem wohlverdienten Ulraub. Es sei ihnen natürlich gegönnt.  :)
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)