Das Ganze funktioniert auch sehr gut und läuft soweit stabil.
Seit ein paar Tage (nach dem letzten Pihole Release ?) sehe ich im Log ca. alle 10 Sekunden zwei DNS-Abfragen, wo der Raspberry sich selbst bei der Fritz!Box abfragt.
Es gibt nichts in Pi-hole das dies auslösen könnte. Welche Client IP ist dies? Halten sie die Maus über die Schriftzug "pi.hole" in der Spalte "Client" um dies zu sehen
Leider wird mir die IP nicht angezeigt, wenn ich die Maus auf "pi.hole" halte.
Im Query Log steht am Seitenende noch: " Note: Queries for pi.hole and the hostname are never logged." Ggfs. hat dies Auswirkungen.
Weiterhin sehe ich im Debug-Log einen Fehler:
Blockquote
*** [ DIAGNOSING ]: Discovering active DHCP servers (takes 10 seconds)
Scanning all your interfaces for DHCP servers
Timeout: 10 seconds
WARN: Could not sendto() in send_dhcp_discover() (/__w/FTL/FTL/src/dhcp-discover.c:233): Network is unreachable
Received 548 bytes from eth0:192.168.178.1
Obwohl die Fritz!Box via SSH über den Raspberry erreichbar ist.
Ich habe ein wenig rum probiert und festgestellt, dass nslookup nicht den Hostnamen des Pihole (pihole.fritz.box) auflösen konnte. Es kam immer NXDOMAIN
Nach Einschalten der DEBUG-Logs für Pihole-FTL habe ich mir das Pihole-FTL Log angeschaut
[2021-10-26 22:19:33.394 29540M] **** new UDP IPv4 query[A] query "pihole.fritz.box" from eth0:192.168.178.15#45800 (ID 68, FTL 80228, src/dnsmasq/forward.c:1575)
[2021-10-26 22:19:33.394 29540M] pihole.fritz.box is not known
[2021-10-26 22:19:33.395 29540M] DNS cache: 192.168.178.15/pihole.fritz.box is not blocked
[2021-10-26 22:19:33.395 29540M] Processing FTL hook from src/dnsmasq/forward.c:520...
[2021-10-26 22:19:33.395 29540M] Flags: F_FORWARD F_IPV4 F_SERVER
[2021-10-26 22:19:33.395 29540M] **** forwarded pihole.fritz.box to 192.168.178.1#53 (ID 68, src/dnsmasq/forward.c:520)
[2021-10-26 22:19:33.395 29540M] Processing FTL hook from src/dnsmasq/forward.c:1573...
[2021-10-26 22:19:33.395 29540M] Flags: F_FORWARD F_IPV4 F_QUERY
[2021-10-26 22:19:33.395 29540M] **** new UDP IPv4 query[AAAA] query "pihole.fritz.box" from eth0:192.168.178.15#45800 (ID 69, FTL 80229, src/dnsmasq/forward.c:1575)
[2021-10-26 22:19:33.395 29540M] pihole.fritz.box is not known
[2021-10-26 22:19:33.395 29540M] DNS cache: 192.168.178.15/pihole.fritz.box is not blocked
[2021-10-26 22:19:33.396 29540M] Processing FTL hook from src/dnsmasq/forward.c:520...
[2021-10-26 22:19:33.396 29540M] Flags: F_FORWARD F_IPV4 F_SERVER
[2021-10-26 22:19:33.396 29540M] **** forwarded pihole.fritz.box to 192.168.178.1#53 (ID 69, src/dnsmasq/forward.c:520)
[2021-10-26 22:19:33.396 29540M] Processing FTL hook from src/dnsmasq/rfc1035.c:912...
[2021-10-26 22:19:33.396 29540M] Flags: F_FORWARD F_NEG F_NXDOMAIN F_UPSTREAM
[2021-10-26 22:19:33.396 29540M] **** got upstream reply from 192.168.178.1#53: pihole.fritz.box is (NXDOMAIN) (ID 68, src/dnsmasq/rfc1035.c:912)
[2021-10-26 22:19:33.396 29540M] Set reply to NXDOMAIN (2) in src/dnsmasq_interface.c:2112
[2021-10-26 22:19:33.396 29540M] Processing FTL hook from src/dnsmasq/rfc1035.c:912...
[2021-10-26 22:19:33.396 29540M] Flags: F_FORWARD F_NEG F_NXDOMAIN F_UPSTREAM
[2021-10-26 22:19:33.396 29540M] **** got upstream reply from 192.168.178.1#53: pihole.fritz.box is (NXDOMAIN) (ID 69, src/dnsmasq/rfc1035.c:912)
[2021-10-26 22:19:33.396 29540M] Set reply to NXDOMAIN (2) in src/dnsmasq_interface.c:2112
[2021-10-26 22:19:33.397 29540M] Processing FTL hook from src/dnsmasq/forward.c:1573...
[2021-10-26 22:19:33.397 29540M] Flags: F_FORWARD F_IPV4 F_QUERY
[2021-10-26 22:19:33.397 29540M] Replying to pihole with interface-local IP address
[2021-10-26 22:19:33.397 29540M] Preparing reply for "pihole", EDE: N/A
[2021-10-26 22:19:33.397 29540M] Forced DNS reply to IP
[2021-10-26 22:19:33.397 29540M] Flags: F_IPV4
[2021-10-26 22:19:33.397 29540M] Adding RR: "pihole A 192.168.178.15"
[2021-10-26 22:19:33.397 29540M] Processing FTL hook from src/dnsmasq_interface.c:347...
[2021-10-26 22:19:33.397 29540M] Flags: F_HOSTS F_IPV4
[2021-10-26 22:19:33.397 29540M] FTL_reply(): Query 70 has not been found
[2021-10-26 22:19:33.397 29540M] Processing FTL hook from src/dnsmasq/forward.c:1573...
[2021-10-26 22:19:33.397 29540M] Flags: F_FORWARD F_IPV4 F_QUERY
[2021-10-26 22:19:33.398 29540M] Replying to pihole with interface-local IP address
[2021-10-26 22:19:33.398 29540M] Preparing reply for "pihole", EDE: N/A
[2021-10-26 22:19:33.398 29540M] Forced DNS reply to IP
[2021-10-26 22:19:33.398 29540M] Flags: F_IPV6
[2021-10-26 22:19:33.398 29540M] Adding RR: "pihole AAAA fd00::dea6:32ff:fe77:1955"
[2021-10-26 22:19:33.398 29540M] Processing FTL hook from src/dnsmasq_interface.c:375...
[2021-10-26 22:19:33.398 29540M] Flags: F_HOSTS F_IPV6
[2021-10-26 22:19:33.398 29540M] FTL_reply(): Query 71 has not been found
[2021-10-26 22:19:34.645 29540M] Processing FTL hook from src/dnsmasq/forward.c:1573...
[2021-10-26 22:19:34.645 29540M] Flags: F_FORWARD F_IPV4 F_QUERY
"domain fritz.box" habe ich aus /etc/resolv.conf gelöscht und den Pihole anschließend neu gestartet.
Anschließend wurde nslookup wieder aufgelöst, jedoch weiterhin die Abfragen im Query Log.
Also erst einmal sind die Abfragen an sich nichts ungewöhnliches. Dein Pi-Device sucht halt die IP zu pihole. Kann es sein, dass du das als hostnamen gesetzt hast? Was steht denn in /etc/hosts?
(Pi-hole schreibt sich selbst mit pi.hole)
Zur Wiederholung der Anfragen: du hast den Cache deaktiviert. Also muss das jedes Mal neu gemacht werden. Die einzige Frage die bleibt: welcher Process fragt das an?
Der Hostname des Raspberry ist pihole.
Wenn ich einen nslookup auf pihole.fritz.box mache wird mir die richtige IP angezeigt.
Wenn ich einen nslookup auf pi.hole mache wird mir auch die richtige IP angezeigt.
Über Nacht sind die Anfragen wieder "schlimmer" geworden, teilweise 10x Sekunde.
Ausgehend immer vom raspberry/pihole.
Wie kann ich denn herausfinden, welcher Process die Anfragen triggert?
EDIT:
Ich habe noch mal das DEBUG-Log von Pihole-FTL eingeschaltet.
Leider passt keine der dort aufgeführten IDs zu einem laufenden Prozess via ps -e.
Es scheint so, als ob die Einträge generiert werden, wenn ich das Webinterface per Browser aufrufe.
Dabei ist es egal, von welchem Gerät dies geschieht.
Wie rufst du denn das web interface auf? Also über welche Adresse? Normalerweise werden Anfragen nach pi.hole und dem hostnamen nicht geloggt, damit eben beim Aufrufen des webinterfaces nicht alles zugespammt wird.
Ich vermisse den (auf Debian) üblichen 127.0.1.1 Eintrag in /etc/hosts. E.g.
127.0.1.1 pihole
wenn der hostname in /etc/hostname "pihole" lautet. Da bei DNS Anfragen standardmäßig /etc/hosts bevorzugt wird könnte dies Anfragen für diesen hostname über /etc/resolv.conf an den Router möglicherweise verhindern.
Interessant. Meines Wissens wird /etc/hostname beim boot verwendet um den Hostnamen erstmals festzulegen. Da könntest du mal dmesg ausführen und schauen was da zu allererst gesetzt wird. Es kann aber sein, dass dies später via DHCP/RA vom Router überschrieben wird, oder eben über PTRs abgefragt, insbesondere wenn die Datei leer ist, da bin ich mir nicht sicher.
Unabhängig von den Dateien kann man via hostname Befehl den Hostnamen temporär (bis zum nächsten Neustart) festlegen, was dann üblicherweise Vorrang hat, sofern ein Programm nicht explizit nur den Inhalt der Datei ließt. Aber ich weiß nicht welche Systembibliothek das wie regelt.
In jedem Fall macht es Sinn, dass /etc/hostname denselben Hostnamen enthält wie der welcher von hostname ausgegeben wird und um PTRs und/oder Umwege für lokale Zugriffe zu vermeiden eben auch derselbe Hostname für eine loopback IP in /etc/hosts eingetragen ist.
hostname benutzt folgende Funktionen im Hintergrund (man sethostname):
GETHOSTNAME(2) Linux Programmer's Manual GETHOSTNAME(2)
NAME
gethostname, sethostname - get/set hostname
SYNOPSIS
#include <unistd.h>
int gethostname(char *name, size_t len);
int sethostname(const char *name, size_t len);
Feature Test Macro Requirements for glibc (see fea‐
ture_test_macros(7)):
gethostname():
Since glibc 2.12: _BSD_SOURCE || _XOPEN_SOURCE >= 500
|| /* Since glibc 2.12: */ _POSIX_C_SOURCE >= 200112L
sethostname():
Since glibc 2.21:
_DEFAULT_SOURCE
In glibc 2.19 and 2.20:
_DEFAULT_SOURCE || (_XOPEN_SOURCE && _XOPEN_SOURCE < 500)
Up to and including glibc 2.19:
_BSD_SOURCE || (_XOPEN_SOURCE && _XOPEN_SOURCE < 500)
DESCRIPTION
These system calls are used to access or to change the
system hostname. More precisely, they operate on the
hostname associated with the calling process's UTS name‐
space.
sethostname() sets the hostname to the value given in the
character array name. The len argument specifies the
number of bytes in name. (Thus, name does not require a
terminating null byte.)
gethostname() returns the null-terminated hostname in the
character array name, which has a length of len bytes.
If the null-terminated hostname is too large to fit, then
the name is truncated, and no error is returned (but see
NOTES below). POSIX.1 says that if such truncation oc‐
curs, then it is unspecified whether the returned buffer
includes a terminating null byte.
[...]
