Lokale DNS-Domains werden nicht aufgelöst, wenn Pi-hole über Router konfiguriert ist

Beobachtetes und erwartetes Verhalten

Pi-hole läuft auf einem Linux-System (Ubuntu 22.04) im Dockercontainer mit network_mode: host.
Ich habe einen Speedport Smart 4-Router, für welchen ich den primären und sekundären DNS-Server mit meiner lokalen Server-IP (bspw. 192.168.2.123) angegeben habe.

Der Pi-hole fungiert nur für DNS, ich habe ihn nicht als DHCP-Server eingerichtet, da ich mir die mühselige Arbeit, die ganzen statischen IPs wieder neu zu setzen, sparen wollte und außerdem eigentlich mit der Netzwerkoberfläche vom Speedport ganz zufrieden bin.

Soweit funktioniert auch alles und die Anfragen werden korrekt durchgeleitet, allerdings werden in meiner Konfiguration nur die lokalen Hostnames (wie unter /etc/hostname etc. angegeben) aufgelöst, allerdings nicht die lokal gesetzten DNS-Einträge.

Diese habe ich folgendermaßen definiert:

Meine Domainendung lautet nicht wirklich .local, ich habe das jetzt hier nur so zur Veranschaulichung angegeben.

Ein dig auf bspw. home.local (welches beispielsweise auf meinen Server unter 192.168.2.123 zeigen soll) gibt mir folgenden Output:

; <<>> DiG 9.18.1-1ubuntu1.3-Ubuntu <<>> home.local
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57927
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

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

;; Query time: 808 msec
;; SERVER: 192.168.2.1#53(192.168.2.1) (UDP)
;; WHEN: Thu Feb 23 15:46:51 CET 2023
;; MSG SIZE  rcvd: 37

Ergo: kein Ergebnis.

Wenn ich ein dig über meinen Server mit dem Pi-hole mache, klappt es:

; <<>> DiG 9.18.1-1ubuntu1.3-Ubuntu <<>> home.local @192.168.2.123
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39142
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

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

;; ANSWER SECTION:
home.local.		0	IN	A	192.168.2.123

;; Query time: 0 msec
;; SERVER: 192.168.2.123#53(192.168.2.123) (UDP)
;; WHEN: Thu Feb 23 15:48:12 CET 2023
;; MSG SIZE  rcvd: 53

Muss ich für jeden Rechner in meinem Netzwerk manuell den DNS-Server auf meine Server-IP setzen? Das ist doch eigentlich nicht Sinn der Sache, oder?

Vielen Dank vorab für jede Hilfe.

Dein zweites Ergbenis zeigt, dass Pi-hole die korrekte Antwort liefert, sofern die DNS-Anfrage direkt an Pi-hole gerichtet wird.
Tauchen denn in beiden Fällen entsprechende Einträge in Pi-holes Query Log auf?

Gibt es einen Grund, warum Du den DHCP-Server in Deinem Router nicht so konfigurierst, dass er Pi-hole als lokalen DNS-Server via DHCP verteilt?

Aktuell verwendet Dein Router Pi-hole als Upstream-DNS-Server, d.h. die DNS-Anfragen Deiner Clients gehen zunächst an Deinen Router, und dessen interner DNS-Server entscheidet dann, ob er die Anfrage direkt beantwortet oder an Pi-hole weiterleitet.

Deine obigen dig-Ergebnisse legen nahe, dass Dein Router Anfragen für die lokale Domäne (<hostname>.<localdomain>) nicht an Pi-hole weiterleitet.
Du müsstest also einen Weg finden, das in Deinem Router zu ändern, oder Deinen Router so konfigurieren, dass er Pi-hole via DHCP verteilt.

Einen Query Log-Eintrag bekomme ich in beiden Fällen:


Ergo einmal direkt von meinem Rechner (bei dig @192.168.2.123 home.local) und einmal vom Router (bei dig home.local).

Wie kann ich meinen Speedport einrichten, dass er Pi-hole als lokalen DNS-Server via DHCP verteilt? Meinst du damit, dass ich dann Pi-hole als DHCP-Server nutze?

Das klingt einleuchtend. Allerdings frage ich mich, warum er die Anfrage nicht weiterleitet, wenn er keine Antwort bekommt.

Hast du zufällig eine Idee, wie das beim Speedport Smart möglich ist? Ich stecke leider im Networking nicht tief genug drin.

Das bedeutet dann, dass Dein Router die DNS-Anfrage sehr wohl an Pi-hole leitet, Pi-hole dafür auch die Antwort an den Rouer liefert, dieser aber die Antwort unterdrückt.

Das könnte ein Sicherheits-Feature Deines Routers sein, um sogenannte DNS-Rebind-Angriffe zu unterbinden:
Öffentliche DNS-Server liefern normalerwiese ausschließlich öffentliche IP-Adressen zurück. DNS-Antworten eines Upstream-DNS-Servers können vom Router verworfen werden, wenn die Antwort eine private IP-Adresse aus Deinem Heimnetz enthält.

Möglicherweise lassen sich in Deinem Router dafür Ausnahmen definieren, oder das Feature lässt sich insgesamt abschalten. Für den Betrieb mit Pi-hole als Upstream wäre das sinnvoll.

Aber das bräuchtest Du nicht, wenn Du stattdessen den DHCP-Server in Deinem Router so konfigurierst, dass er Pi-hole als lokalen DNS-Server via DHCP verteilt.

Erst wenn Dein Speedport weder lokale DNS-Einstellungen für DHCP noch DNS-Rebind-Schutz-Einstellungen bietet, bliebe noch das Abschalten des DHCP-Servers im Router und das Aktivieren von Pi-holes DHCP-Server.

Vielen Dank für deine Antwort! In der Tat hat mein Router einen DNS-Rebind-Schutz aktiviert. Dafür lassen sich Ausnahmen erstellen, allerdings muss ich dafür eine Domain angeben. Da der Pi-hole ja über meinen Server läuft, gibt es da theoretisch keine Domain, oder? Dementsprechend müsste ich den DNS-Rebind-Schutz deaktivieren.

Ich habe leider noch nicht rausgefunden, wie das funktioniert, allerdings habe ich diesen Artikel hier gefunden, der das Vorgehen mit dem Speedport beschreibt, den werde ich noch mal durchgehen.

Das bedeutet also: wenn ich den DNS-Rebind-Schutz aktiviere, sollte es funktionieren?

Nochmals vielen Dank Bucking_Horn, das Deaktivieren des DNS-Rebind-Schutzes hat das Problem gelöst. Ich werde mich trotzdem noch mal kundig machen zwecks DHCP-Funktion des Pi-holes.

I think I found a PDF manual for your router:

but I'm not sure if this model is capable of setting custom DNS servers for the DHCP (I don't speak enough German to find it out).

Thanks! I know how to set the DHCP server manually, but got it working differently as well now.

This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.