[Gelöst] Pi-hole als manueller DNS-Server: Auflösen lokaler (kurzer) Hostnamen geht nicht

Irgendwie kommt das hier immer wieder vor, aber genau meine Problematik habe ich nicht gefunden:

Ich habe Pi-hole auf einem Raspi 3B mit Bookworm (32bit) neu aufgesetzt.

Mein Router ist eine Fritzbox, die auch der DHCP-Server für das lokale Netz ist. Sie hat externe DNS-Server eingetragen. Jeder lokale Client, der Pi-hole benutzt, hat dann die IP von diesem als DNS-Server eingetragen. So auch mein Ubuntu-PC.

Jetzt habe ich das bekannte Problem, dass ich lokale Clients nicht mehr finde, wenn ich den Hostnamen alleine verwende:

~$ ping Anlage
ping: Anlage: Temporärer Fehler bei der Namensauflösung

Mit dem Domainnamen der Fritzbox geht es:

~$ ping Anlage.fritz.box
PING Anlage.fritz.box (192.168.178.41) 56(84) bytes of data.
64 bytes from Anlage.fritz.box (192.168.178.41): icmp_seq=1 ttl=255 time=122 ms
64 bytes from Anlage.fritz.box (192.168.178.41): icmp_seq=2 ttl=255 time=83.6 ms
^C
--- Anlage.fritz.box ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 83.579/102.993/122.408/19.414 ms

Was muss ich beim Pi-hole konfigurieren, damit auch die kurze Variante nur mit Hostnamen wieder geht?

Ich habe aktuell unter Settings->DNS die IP der Fritbox als "Custom Upstream DNS Server" eingetragen und das Conditional forwarding mit dem Subnetz und der Adresse der Fritzbox aktiviert, dabei die lokale Domain leer gelassen:

dig auf dem Raspi liefert das gewünschte:

:~ $ dig @192.168.178.1 A Anlage

; <<>> DiG 9.18.24-1-Raspbian <<>> @192.168.178.1 A Anlage
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36747
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 3

;; QUESTION SECTION:
;Anlage.				IN	A

;; ANSWER SECTION:
Anlage.			9	IN	A	192.168.178.41

;; AUTHORITY SECTION:
Anlage.			9	IN	NS	fritz.box.

;; ADDITIONAL SECTION:
fritz.box.		9	IN	A	192.168.178.1
fritz.box.		9	IN	AAAA	fd00::7642:7fff:fe4e:8e56
fritz.box.		9	IN	AAAA	2002:95ac:a8ee:0:7642:7fff:fe4e:8e56

;; Query time: 9 msec
;; SERVER: 192.168.178.1#53(192.168.178.1) (UDP)
;; WHEN: Fri Jun 07 15:56:13 CEST 2024
;; MSG SIZE  rcvd: 135

Danke für Eure Hinweise! :wink:

Ich habe mal ein Debug-Log hochgeladen: https://tricorder.pi-hole.net/nPpV7mp6/

Servus.
Trage ins Feld "Local Domain name (optional)" fritz.box ein :wink:

Habe ich auch schon getan - ändert leider nichts am Problem.

Auf dem Pi-hole-Raspi in der Shell geht die Hostnamenangabe:

~ $ ping Anlage
PING Anlage.fritz.box (192.168.178.41) 56(84) bytes of data.
64 bytes from Anlage.fritz.box (192.168.178.41): icmp_seq=1 ttl=255 time=6.02 ms
64 bytes from Anlage.fritz.box (192.168.178.41): icmp_seq=2 ttl=255 time=6.33 ms
64 bytes from Anlage.fritz.box (192.168.178.41): icmp_seq=3 ttl=255 time=5.38 ms
^C
--- Anlage.fritz.box ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 5.375/5.909/6.333/0.398 ms

Deine Beobachtung ist wahrscheinlich ein unerwartetes Verhalten von ping:
ping verwendet mehrere Verfahren zur Auflösung von Hostnamen, nicht nur DNS (was im übrigen ping ungeeignet zur Analyse von DNS-Problemen macht).

Unter bestimmten Umständen wird ping bei einfachen (non-dot) Hostnamen einfach nur auf andere Verfahren zugreifen und überhaupt keine DNS-Anfrage generieren. In einem, solchen Fall gäbe es dann auch keine mit dem ping korrespondierende DNS-Anfrage in Pi-holes Query Log.

Die Verwendung von DNS sollte sich aber durch Anfügen der lokalen Domäne oder eines einfachen Punktes für ping erzwingen lassen.

Falls also ein ping name bei Dir nicht mitspielt, versuch's mal mit ping name., also in Deinem Fall z.B. mit ping Anlage..

Unabhängig von Deiner Beobachtung:

Bei Verwendung der FritzBox als Pi-holes alleinigem Upstream-DNS-Server kannst Du Conditional Forwarding getrost deaktivieren: Die FritzBox erhält ja sowieso alle DNS-Anfragen, die von Pi-hole nicht geblockt oder direkt beantwortet werden. CF ist in dieser Konstellation also überflüssig.

Danke!

ping Anlage. liefert, genau wie ping Anlage, das übliche:

$ ping Anlage.
ping: Anlage.: Temporärer Fehler bei der Namensauflösung

Nur das geht:

~$ ping Anlage.fritz.box
PING Anlage.fritz.box (192.168.178.41) 56(84) bytes of data.
64 bytes from Anlage.fritz.box (192.168.178.41): icmp_seq=1 ttl=255 time=14.2 ms
64 bytes from Anlage.fritz.box (192.168.178.41): icmp_seq=2 ttl=255 time=13.2 ms
64 bytes from Anlage.fritz.box (192.168.178.41): icmp_seq=3 ttl=255 time=6.81 ms
^C
--- Anlage.fritz.box ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 6.807/11.416/14.237/3.286 ms

Wohlgemerkt, das gilt für meinen Ubuntu-PC, der den Pi-hole Raspi als DNS-Server vorgegeben hat.

Auf dem Pi-hole-Raspi dagegen:

pi@Pinsel:~ $ ping Anlage
PING Anlage.fritz.box (192.168.178.41) 56(84) bytes of data.
64 bytes from Anlage.fritz.box (192.168.178.41): icmp_seq=1 ttl=255 time=11.8 ms
64 bytes from Anlage.fritz.box (192.168.178.41): icmp_seq=2 ttl=255 time=11.2 ms
^C
--- Anlage.fritz.box ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms
rtt min/avg/max/mdev = 11.240/11.495/11.750/0.255 ms
pi@Pinsel:~ $ ping Anlage.
PING Anlage (192.168.178.41) 56(84) bytes of data.
64 bytes from Anlage.fritz.box (192.168.178.41): icmp_seq=1 ttl=255 time=6.43 ms
64 bytes from Anlage.fritz.box (192.168.178.41): icmp_seq=2 ttl=255 time=5.19 ms
^C
--- Anlage ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms
rtt min/avg/max/mdev = 5.185/5.805/6.426/0.620 ms
pi@Pinsel:~ $ ping Anlage.fritz.box
PING Anlage.fritz.box (192.168.178.41) 56(84) bytes of data.
64 bytes from Anlage.fritz.box (192.168.178.41): icmp_seq=1 ttl=255 time=5.99 ms
64 bytes from Anlage.fritz.box (192.168.178.41): icmp_seq=2 ttl=255 time=6.17 ms
^C
--- Anlage.fritz.box ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 5.992/6.082/6.172/0.090 ms

Alle sind im gleichen Subnetz, also muss der Raspi irgendwas zusätzlich eingestellt haben, was dem Ubuntu-PC fehlt.

Ubuntu verwendet als DNS-Server standardmässig den lokalen systemd-resolved Stub-Resolver.

Was geben denn folgende Kommandos auf dem Ubuntu-Rechner zurück:

dig pi.hole
dig Anlage @192.168.178.99
~$ dig pi.hole

; <<>> DiG 9.18.24-0ubuntu0.22.04.1-Ubuntu <<>> pi.hole
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28811
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;pi.hole.			IN	A

;; ANSWER SECTION:
pi.hole.		0	IN	A	192.168.178.99

;; Query time: 0 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Sat Jun 08 18:17:24 CEST 2024
;; MSG SIZE  rcvd: 52

und

~$ dig Anlage @192.168.178.99

; <<>> DiG 9.18.24-0ubuntu0.22.04.1-Ubuntu <<>> Anlage @192.168.178.99
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 16072
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;Anlage.				IN	A

;; Query time: 4 msec
;; SERVER: 192.168.178.99#53(192.168.178.99) (UDP)
;; WHEN: Sat Jun 08 18:18:18 CEST 2024
;; MSG SIZE  rcvd: 35
``

FritzBoxen können zwar mehrere externe DNS-Server als Upstream verwenden, verteilen aber grundsätzlich nur einen einzigen lokalen DNS-Server. Werksmässig voreingestellt ist das die FritzBox selbst.

Dein Debug Log zeigt, dass das bei Dir der Fall ist:

*** [ DIAGNOSING ]: Discovering active DHCP servers (takes 10 seconds)
   Scanning all your interfaces for DHCP servers
   
   * Received 548 bytes from eth0:192.168.178.1
     Offered IP address: 192.168.178.99
     DHCP options:
      Message type: DHCPOFFER (2)
      router: 192.168.178.1
      dns-server: 192.168.178.1
      domain-name: "fritz.box"

Das würde bedeuten, dass Du Pi-hole als Upstream Deiner FritzBox eingerichtet hast.
DNS-Anfragen nähmen dann folgenden Weg:

Client -> FritzBox -> Pi-hole -> Pi-holes Upstream

Da du schreibst, dass Du wiederum Deine FritzBox als Upstream von Pi-hole konfiguriert hast, hättest Du eine DNS-Endlosschleife konfiguriert.
In der Folge wäre zu erwarten, dass überhaupt keine öffentlichen Namen mehr aufgelöst werden.

Wie hast Du denn die FritzBox zur Verwendung von Pi-hole konfiguriert?
Wie sehen Deine FritzBox-Einstellungen für Pi-hole aus (unter Internet > Zugangsdaten > DNS-Server)?

Da interpretierst Du etwas falsch, glaube ich. Die Fritzbox kennt den Pi-hole-Raspi nur als DHCP-Client. Bei ihr sind als DNS-Server 1.1.1.1 und 9.9.9.9 eingetragen. Nahezu alle Clients der Fritzbox haben die Fritzbox selber als DNS-Server. Ausnahmen sind ein paar Android-Tablets und eben mein Ubuntu-PC. Auf diesen Geräten ist der Raspi als DNS-Server eingetragen.

Also nehmen nur die Android-Dinger (auf denen ich die lokale Hostnamenauflösung nicht benutze) und der PC den Umweg über den Raspi als DNS-Server. Und der kann zwar selber die Hostnamen auflösen (vermutlich, weil er selbst als Client an der Fritzbox hängt), gibt dieses Wissen aber nicht weiter.

Dann sieht Dein Router aktuell Pi-hole überhaupt nicht für die Verwendung in Deinem Netzwerk vor, weder als Upstream noch als lokalen DNS-Server.

In der Folge würden nur die Maschinen Pi-hole als DNS-Server nutzen, die von Dir dafür jeweils manuell konfiguriert wurden.

Ist das die von Dir gewünschte Konfiguration?

Ja, genau.

Gibt es dafür einen Grund?

Welche DNS-Einstellungen hast Du dann auf dem Ubuntu-Rechner konfiguriert?
Ich vermute dann mal, Dir fehlt dort die search domain.

Wie sieht /etc/resolv.conf auf dem Ubuntu-Rechner aus?

grafik

resolv.conf:

# This is /run/systemd/resolve/stub-resolv.conf managed by man:systemd-resolved(8).
# Do not edit.
#
# This file might be symlinked as /etc/resolv.conf. If you're looking at
# /etc/resolv.conf and seeing this text, you have followed the symlink.
#
# This is a dynamic resolv.conf file for connecting local clients to the
# internal DNS stub resolver of systemd-resolved. This file lists all
# configured search domains.
#
# Run "resolvectl status" to see details about the uplink DNS servers
# currently in use.
#
# Third party programs should typically not access this file directly, but only
# through the symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a
# different way, replace this symlink by a static file or a different symlink.
#
# See man:systemd-resolved.service(8) for details about the supported modes of
# operation for /etc/resolv.conf.

nameserver 127.0.0.53
options edns0 trust-ad
search .

Da steht "do not edit" drin... Das empfohlene resolvectl status liefert

~$ resolvectl status
Global
       Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub

Link 2 (enp3s0)
    Current Scopes: DNS
         Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 192.168.178.99
       DNS Servers: 192.168.178.99 fd00::7642:7fff:fe4e:8e56 2002:95ac:a8ee:0:7642:7fff:fe4e:8e56

Link 3 (wlp4s0)
Current Scopes: none
     Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

Normalerweise übernimmt ein DHCP-Client die search domain aus dem domain-name vom DHCP-Server.

Dein Debug log zeigt, dass das prinzipiell funktioniert:

*** [ DIAGNOSING ]: contents of /etc

-rw-r--r-- 1 root root 157 Jun  5 18:41 /etc/resolv.conf
   search fritz.box
   nameserver 192.168.178.1

Auf Deinem Ubuntu-Rechner steht hier:

Das würde zumindest erklären, warum ping auf Ubuntu den Hostnamen nicht um die lokale search domain erweitert.

Möglicherweise übernimmt Ubuntu durch das manuelle Setzen des DNS-Servers diese Information nicht mehr.

Du müsstest also nach Wegen suchen, diese auf Ubuntu ebenfalls manuell zu setzen.

Alternativ lässt Du die FritzBox Pi-hole als lokalen DNS-Server verteilen.

1 Like

Du hast mich auf die richtige Spur gebracht!

Die Konfiguration in /etc/resolv.conf wird dynamisch zusammengebaut. Die Domäneninformation (welche lokal durch sucht werden sollen) stammt dabei aus dem Inhalt von /etc/systemd/resolved.conf. Da ist alles auskommentiert - damit search gefüllt wird, muss der Eintrag Domains= aktiv und in meinem Fall auf Domains=fritz.box gesetzt werden.

Mit systemctl restart systemd-resolved wird die Änderung aktiv.

Jetzt geht es wie gewünscht:

~$ ping Anlage
PING Anlage.fritz.box (192.168.178.41) 56(84) bytes of data.
64 bytes from Anlage.fritz.box (192.168.178.41): icmp_seq=1 ttl=255 time=12.9 ms
64 bytes from Anlage.fritz.box (192.168.178.41): icmp_seq=2 ttl=255 time=5.99 ms
^C
--- Anlage.fritz.box ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 5.994/9.458/12.923/3.464 ms

Es wäre möglcherweise hilfreich gewesen, die manuelle DNS-Konfiguration von Einzelrechnern gleich anfangs deutlich herauszustellen. :wink: (Ich hab das mal im Titel ergänzt, für Leute mit ähnlichen Fragestellungen.)

Auch wenn Dein ping-Problem sich durch manuelles Hinzufügen der search domain jetzt erledigt hat:
dig Anlage @192.168.178.99 hätte eigentlich auch funktionieren müssen, da hier ja Pi-hole direkt befragt wurde, und Pi-hole seinerseits die FritzBox befragt.

Was hat Pi-hole zu dieser Anfrage im Query Log angezeigt?
Wie wurde die Anfrage verarbeitet und weitergeleitet?

~$ dig Anlage @192.168.178.99

; <<>> DiG 9.18.24-0ubuntu0.22.04.1-Ubuntu <<>> Anlage @192.168.178.99
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 27347
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;Anlage.				IN	A

;; Query time: 4 msec
;; SERVER: 192.168.178.99#53(192.168.178.99) (UDP)
;; WHEN: Sat Jun 08 19:35:17 CEST 2024
;; MSG SIZE  rcvd: 35

Im Pi-hole-Log:

Jun  8 19:35:17: query[A] Anlage from 192.168.178.27
Jun  8 19:35:17: config Anlage is NXDOMAIN

Dann hast Du wahrscheinlich die Weiterleitung von DNS-Anfragen für einfache Hostnamen in Pi-hole verboten, via Never forward non-FQDN A and AAAA queries unter Settings | DNS.

Ein öffentlicher Upstream könnte mit einfachen Hostnamen ja normalerweise auch nichts anfangen.

In Deinem Fall ist ja aber die FritzBox der Upstream, so dass Du den Haken entfernen kannst.
Dann sollte auch diese Anfrage erfolgreich laufen.

1 Like

Yepp, das geht jetzt auch!

Danke vielmals. :+1: