Recursive DNS auf PiHole funktioniert nicht mehr?

Hallo,

ich habe mir gestern auf meinem PiHole einen Recursiven DNS Server nachinstalliert. Mit unbound. Es hat auch gut funktioniert ca. 12h lang. Heute habe ich das bemerkt:

.178.113 ist der Raspberry Pi

Es geht keine DNS Anfrage mehr durch, deshalbb musste ich jetzt wieder 1.1.1.1 aktivieren. Weiß jemand woran sowas liegt, denn:

unbound funktioniert normal, nur nicht mit PiHole.
Zusätzliche Informationen:
-Ich habe das Gerät mehrmals neugestartet
-Unbound manuell neugestartet
-mit 1.1.1.1 geht alles wieder
-Es hatte gestern funktioniert und heute nicht mehr

Answer 1

[medmonk]

Hast du deinem Pi in deinen Router-Einstellungen eine feste IP zu gewiesen?

Gut möglich, dass dein Router lediglich eine neue IP zugewiesen hat und es deshalb Probleme mit deinem Pi gibt. Ist das Dashboard von Pi-hole jetzt noch erreichbar? Ich hatte bei der Einrichtung selber vergessen, einen Haken zu setzen.

Woher ich das weiß: Berufserfahrung – UI/UX Designer, Full-Stack Developer

Comments

[maximilian15366]

Ja die IP ist Statisch und die Oberfläche ist die ganze Zeit erreichbar gewesen

Answer 2

[Bushmills145]

Query zum Testen vom unbound auf dem raspi mal einen anderen host als den von Google, denn laut dig-output ist der bereits gecached. Damit muss unbound diesen nicht mittels Anfragen zu dessen autoritativen Server in Erfahrung bringen.

Sollte unbound aus irgend einem Grund keinen Internet-Zugang haben, würde das mit dem Google-host nicht bemerkt werden.

Woher ich das weiß: Berufserfahrung – Ich weiß, wie man "Computer" buchstabiert.

Comments

[maximilian15366]

Danke einen schritt weiter: https://picr.eu/i/5PcVK

[Bushmills145]

@maximilian15366

NXDOMAIN .. Nimm auch mal einen bestehenden host - allerdings ist der negative Bescheid schon Hinweis darauf, dass Netzzugriff stattfindet.

[maximilian15366]

https://picr.eu/i/5PhSh ja sry ich glaub minecraft123.net existiert überhaupt nicht
Übrigends habe ich in der Frage noch ein Log Bild hinzugefügt

[Bushmills145]

@maximilian15366

Gut, den kann er auflösen. Geht das auch noch von anderen Maschinen im LAN, pihole auf raspi befragend?

[maximilian15366]

@Bushmills145

Ich weiß nicht genau was du meinst, ob jetzt ein anderes Gerät im Netzwerk die Domain auflösen kann? Wie soll ich das machen? (Kann sonst gleich noch ein LOG hochladen)

------------------------------------------------------------------------------------------------------

C:\Users\winke>nslookup -vc www.example.com 192.168.178.113

Server: pi.hole

Address: 192.168.178.113

Nicht autorisierende Antwort:

Name:  www.example.com

Addresses: 2606:2800:220:1:248:1893:25c8:1946

     93.184.216.34

C:\Users\winke>nslookup -vc www.example.com 192.168.178.113:5335

*** Die Serveradresse für "192.168.178.113:5335" kann nicht gefunden werden:

Server: pi.hole

Address: 192.168.178.113

Nicht autorisierende Antwort:

Name:  www.example.com

Addresses: 2606:2800:220:1:248:1893:25c8:1946

     93.184.216.34

[Bushmills145]

@maximilian15366

Von anderem Computer aus: dig @pihole example.com

[maximilian15366]

@Bushmills145

dig funktioniert weder über powershell noch über cmd
Zusatz: Irgendwie zeigt der im Log nur pi.hole an obwohl ich über mein PC eine Domain abgefragt habe

[Bushmills145]

@maximilian15366

Was zeigt dig an, wenn es "nicht funktioniert"?

[maximilian15366]

@Bushmills145

der befehl ist nicht verfgbar

[Bushmills145]

@maximilian15366

Dann wirst du es erst installieren müssen.

[maximilian15366]

@Bushmills145

Failed to connect to DNS server (192.168.178.113:5335).

[Bushmills145]

@maximilian15366

Da wird wohl dein Problem sein: pihole an sich scheint zu funktionieren, aber andere Computer in deinem LAN können nicht auf dessen rekursiven Nameserver zugreifen.

Schau auf dem raspi, mit netstat -tunlp, ob unbound überhaupt an das Ethernet-Interface vom raspi gebunden ist, oder lediglich an sein loopback-interface (das mit der 127.0.0.1 Adresse).

[maximilian15366]

@Bushmills145

pi@raspberrypi:~ $ sudo netstat -tunlp

Active Internet connections (only servers)

Proto Recv-Q Send-Q Local Address      Foreign Address     State    PID/Program name

tcp    0   0 127.0.0.1:4711     0.0.0.0:*        LISTEN   16467/pihole-FTL

tcp    0   0 0.0.0.0:10000      0.0.0.0:*        LISTEN   684/perl

tcp    0   0 127.0.0.1:5335     0.0.0.0:*        LISTEN   16970/unbound

tcp    0   0 127.0.0.1:8953     0.0.0.0:*        LISTEN   16970/unbound

tcp    0   0 0.0.0.0:53       0.0.0.0:*        LISTEN   16467/pihole-FTL

tcp    0   0 0.0.0.0:22       0.0.0.0:*        LISTEN   525/sshd: /usr/sbin

tcp    0   0 0.0.0.0:80       0.0.0.0:*        LISTEN   6946/lighttpd

tcp6    0   0 ::1:4711        :::*          LISTEN   16467/pihole-FTL

tcp6    0   0 :::53          :::*          LISTEN   16467/pihole-FTL

tcp6    0   0 :::22          :::*          LISTEN   525/sshd: /usr/sbin

tcp6    0   0 :::80          :::*          LISTEN   6946/lighttpd

udp    0   0 127.0.0.1:5335     0.0.0.0:*              16970/unbound

udp    0   0 0.0.0.0:5353      0.0.0.0:*              388/avahi-daemon: r

udp    0   0 0.0.0.0:10000      0.0.0.0:*              684/perl

udp    0   0 0.0.0.0:40458      0.0.0.0:*              388/avahi-daemon: r

udp    0   0 0.0.0.0:53       0.0.0.0:*              16467/pihole-FTL

udp    0   0 0.0.0.0:68       0.0.0.0:*              757/dhcpcd

udp6    0   0 :::5353         :::*                388/avahi-daemon: r

udp6    0   0 :::43263        :::*                388/avahi-daemon: r

udp6    0   0 :::53          :::*                16467/pihole-FTL

[Bushmills145]

@maximilian15366

udp    0   0 127.0.0.1:5335     0.0.0.0:*              16970/unbound

unbound hört auf port 5335 lediglich auf das loopback interface - und kann damit nicht von anderen Maschine im Netz befragt werden.

Aber eigentlich würdest du ja vermutlich wollen, dass dnmask (also FTL) die eingehenden Anfragen auf port 53 lokal weiterleitet an unbound, so dass jeder ledglich port 53 befragt.

[maximilian15366]

@Bushmills145

Ist das nicht egal weil PiHole sowieso im normal Fall das einzige Gerät ist was abfragen macht?
(Ich hatte mal PiHole umconfiguriert von wireless auf eth)

[Bushmills145]

@maximilian15366

Dein Problem ist aber nicht "pihole macht Anfragen" sondern "Andere senden Anfragen an pihole" - womit pihole auch nicht das einzige Gerät ist. Jedes Gerät, welches pihole verwenden möchte, sendet ebenfalls Anfragen - zum pihole halt. Und bekommt da keine richtige Antwort.

[maximilian15366]

@Bushmills145

Aber anfragen an PiHole gehen ja nur die umleitung auf unbound (oder von unbound zum pihole) gehen ja nicht. Wenn ich unbound rausnehme und PiHole zu 1.1.1.1 umleiten lasse geht es ja.

[Bushmills145]

@maximilian15366

Ja, die sollten von FTL zum unbound weitergeleitet werden. Aber anscheinend passiert das nicht.

[Bushmills145]

@maximilian15366

Wo kommt der port in "Failed to connect to DNS server (192.168.178.113:5335)." her, hast du den beim Aufruf von dig selbst angegeben?

[maximilian15366]

@Bushmills145

Ich habe den Server so angegeben. Ich habe jetzt nochmal dig probiert wo nur unbound in pihole festegelt war. Keine Rückmeldung und in PiHole kriegt PiHole keine Antwort von unbound.
.
PS C:\Windows\system32> dig pi.hole example.com

; <<>> DiG 9.16.28 <<>> pi.hole example.com

;; global options: +cmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2691

;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:

; EDNS: version: 0, flags:; udp: 1232

;; QUESTION SECTION:

;pi.hole.            IN   A

;; ANSWER SECTION:

pi.hole.        0    IN   A    192.168.178.113

;; Query time: 2 msec

;; SERVER: 192.168.178.113#53(192.168.178.113)

;; WHEN: Sat Jul 15 19:42:11 Mitteleuropõische Sommerzeit 2023

;; MSG SIZE rcvd: 52

PS C:\Windows\system32> dig example.com

; <<>> DiG 9.16.28 <<>> example.com

;; global options: +cmd

;; connection timed out; no servers could be reached

PS C:\Windows\system32> dig example.com

[Bushmills145]

@maximilian15366

Von einer anderen Maschine aus kannst du Port 5335 nicht befragen, weil der piole auf der Ethernet-Schnittstelle da keinen Dienst daran gebunden hat - also auch nicht unbound.

Den pihole kannst du aber auf port 53 befragen, an welchen FTL gebunden ist - und der soll dann dafür sorgen, dass die Anfrage an unbound weitergeleitet wird. Dieses Weiterleiten sollte FTL an 127.0.0.1:5335 machen, denn auf dem Raspi hört unbound ja auf Port 5335 der loopback-Schnittstelle.