Pi-Hole using "debianserver" as the hostname; this was set in the Debian 11 installation and works, when Pi-Hole is NOT used as a DNS Server.
Actual Behaviour:
The moment when I set my Pi-Hole Machine (a older laptop which runs a lot of services) as the DNS Server in the FRITZ!Box 7530 Router Networksettings machine can't be accsessed under "debianserver" anymore, after I restart my Router.
Pi-Hole automatically assigns pi.hole as the hostname.
However: Pihole was never instructed to use that hostname. Staying on pi.hole Hostname is not an option and it literally doesn't even show up anywhere.
$ cat /etc/pihole/pihole-FTL.conf
#; Pi-hole FTL config file
#; Comments should start with #; to avoid issues with PHP and bash reading this file
PRIVACYLEVEL=0
RATE_LIMIT=1000/60
$ cat /etc/host
$ cat /etc/hostname
debianserver
I'm not really sure how to solve that issue because for me it doesn't really make sense.
I hope someone can help me out on this one.
Thank you!
Well. No it does not because it returns the localhost adress which breaks everything.
I assume it's the IP Adress of the Loopback Adapter, which is for whatever reason returned. I did however selected eno0 (my LAN Interface) when setting up Pihole via the install script.
$ ping debianserver
Ping wird ausgeführt für debianserver.fritz.box [127.0.1.1] mit 32 Bytes Daten:
Antwort von 127.0.1.1: Bytes=32 Zeit<1ms TTL=128
Antwort von 127.0.1.1: Bytes=32 Zeit<1ms TTL=128
Antwort von 127.0.1.1: Bytes=32 Zeit<1ms TTL=128
Antwort von 127.0.1.1: Bytes=32 Zeit<1ms TTL=128
Ping-Statistik für 127.0.1.1:
Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0
(0% Verlust),
Ca. Zeitangaben in Millisek.:
Minimum = 0ms, Maximum = 0ms, Mittelwert = 0ms
Pi.Hole Pinging is also not returning the correct IP
ping pi.hole
Ping wird ausgeführt für pi.hole [fe80::REDACTED:REDACTED:REDACTED:REDACTED%20] mit 32 Bytes Daten:
Antwort von fe80::REDACTED:REDACTED:REDACTED:REDACTED%20: Zeit<1ms
Antwort von fe80::REDACTED:REDACTED:REDACTED:REDACTED%20: Zeit<1ms
Antwort von fe80::REDACTED:REDACTED:REDACTED:REDACTED%20: Zeit<1ms
Antwort von fe80::REDACTED:REDACTED:REDACTED:REDACTED%20: Zeit<1ms
Ping-Statistik für fe80::REDACTED:REDACTED:REDACTED:REDACTED%20:
Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0
(0% Verlust),
Ca. Zeitangaben in Millisek.:
Minimum = 0ms, Maximum = 0ms, Mittelwert = 0ms
What I find interesting however is the escaped character %20 at the end of the IPv6 adress. I have no idea where that comes from
And this behaviour only applies when I setup the IPv4 Adress of my Machine as a local DNS Server.
That's not a Pi-hole artifact, this would also be the case if you were pinging the hostname of the localhost before you installed Pi-hole. It's configured in /etc/hosts. Eg some Linux setups here all resolve the hostname to 127.0.1.1:
pi@piaware:~ $ ping piaware
PING piaware (127.0.1.1) 56(84) bytes of data.
64 bytes from piaware (127.0.1.1): icmp_seq=1 ttl=64 time=0.110 ms
chris@testmint:~$ ping testmint
PING testmint (127.0.1.1) 56(84) bytes of data.
64 bytes from testmint (127.0.1.1): icmp_seq=1 ttl=64 time=0.023 ms
pi@pihole:~ $ ping pihole
PING pihole (127.0.1.1) 56(84) bytes of data.
64 bytes from pihole (127.0.1.1): icmp_seq=1 ttl=64 time=0.180 ms
One can clearly see that fe80::REDACTED:REDACTED:REDACTED:REDACTED%20 is a correct IP address of your Pi-hole host machine. Compared to that, an incorrect IP address would of course be something like fe80::REDACTED:REDACTED:REDACTED:REDACTED%20, whereas fe80::REDACTED:REDACTED:REDACTED:REDACTED%20 on the other hand could suggest an inappropriately configured static IPv6...
In all honesty:
I presume that you are seeing a valid IP address for your host machine.
Note that in general, ping isn't adequate to analyse DNS issues, even when using hostnames, as it resolves hostnames through a variety of sources, not just DNS.
Use nslookup or dig to analyse DNS issues.
As for your naming issue:
The debian installer creates an entry associating 127.0.1.1 with your hostname in /etc/hosts (see Debian's docs at 5.1.1. The hostname resolution), and Pi-hole is reading that file.
If you are not running software on that host machine that may depend on that value, you may safely remove that 127.0.1.1 debianserver line from your /etc/hosts.
(This should usually be the case for headless server installations)
ICYMI:
I showed that my /etc/host is indeed empty in my initial Post
This was not done by me, it was simply empty.
The first one is without Pi-Hole being the local DNS Server, second one is with Pi-Hole as DNS Server.
$ ip address show
And I really don't understand why the Pi-Hole is shown instead of the Router. I only use Pihole in DNS mode, DHCP is done by my Router and I do input the IP-Adresses of the Machine into the DNS-Fields of the Router.
Well that wasnt helpful of me was it. It's local adresses anyways so I gues Its fine to show them. I hope it helps you more to see everything. I was under the assumption that's what the logtoken is for: to see everything needed.
That file is different from /etc/hosts - note the trailing s.
Please try removing that 127.0.1.1 line as suggested.
You'd then have to restart Pi-hole's DNS resolver, e.g. by running pihole restartdns.
Also, you can send DNS requests to a specific DNS server, e.g.
nslookup debianserver 192.168.178.1
(assuming that 192.168.178.1 is your router's IPv4 address).
That way, you won't have to switch DNS servers in your router to analyse an issue.
A few remarks, not necessarily related to your observation (click for more).
With IPv6, it's wise to keep them redacted, as they may contain your device's MAC address. Part of yours do, so you may want to redact them.
I'd customarily show the last hex digits, so that anyone still can tell IPs apart, and we potentially still can align that with stuff from your debug log.
And the %20 at the end of link-local IPv6 is a zone index, which is used for routing and usually ties the address to a network interface (of which there may be more than one for a given MAC).
My point here was that resolution works as expected, as Pi-hole would make sure that it answers the correct local address on your host in relation to the interface that a request arrives on. This makes me confident that what you see is indeed a correct IP address, regardless what it actually looks like.
Am not sure if thats recommended.
That would mean that if processes on the own host try to lookup their own name debianserver, they wont be able to connect without resorting to external DNS records.
And some use that line to configure the FQDN for the own host:
pi@ph5b:~ $ man hostname
[..]
THE FQDN
The FQDN (Fully Qualified Domain Name) of the system is the name
that the resolver(3) returns for the host name, such as, ursula.ex‐
ample.com. It is usually the hostname followed by the DNS domain
name (the part after the first dot). You can check the FQDN using
hostname --fqdn or the domain name using dnsdomainname.
You cannot change the FQDN with hostname or dnsdomainname.
The recommended method of setting the FQDN is to make the hostname
be an alias for the fully qualified name using /etc/hosts, DNS, or
NIS. For example, if the hostname was "ursula", one might have a
line in /etc/hosts which reads
127.0.1.1 ursula.example.com ursula
Better to just instruct embedded dnsmasq to not read the hosts file with below directive:
pi@ph5b:~ $ man dnsmasq
[..]
-h, --no-hosts
Don't read the hostnames in /etc/hosts.
EDIT: I have this one disabled enabled anyway bc we have local DNS records now
I've removed it in the past and it did impact sudo, which gave an error every time it was invoked, so I put it back.
I believe the order of resolution is controlled in /etc/nsswitch.conf (the hosts line) but I'm not sure if that is still relevant in modern Debian-based OSs. I've never needed to touch it because everything works fine out the box almost all of the time.
The hostname is in /etc/hostname.
(I know you know that, just mentioning for completeness for future visitors finding this thread in case it's useful)
Local processes could also make use of /etc/hostname to retrieve the hostname.
Associating 127.0.1.1 with that hostname is really a Debian-specific hack, to overcome limitations of some (supposedly) desktop software packages (GNOME in particular).
But you are correct - I forgot about the sudo implications.
It doesn't break sudo, though. Without that hostname <-> IP associaton, it just prints out a message any time it is run, which can get annoying.
(I forgot because I replacedhostnamewithunboundin most of my Pi-hole installations (and my unbound is listening on that 127.0.1.1, so Pi-hole's UI would print that name as upstream in its dashboard)).
Rather than removing that line, the correct way to address this would have been to replace 127.0.1.1 with the host's fixed IP, as recommended by the Debian docs I've linked above:
For a system with a permanent IP address, that permanent IP address should be used here instead of 127.0.1.1 .
I wouldnt understand why you would prefer to have this local traffic be broadcasted over an ethernet interface instead of the way way faster lo loopback interface.
It just makes no sense.
Whats wrong with the no-hosts option?
Ow and another aspect of lo vs ethernet, if ethernet disconnects for some reason, processes cant talk to one another internally until connection is restored.
Yes, and that is exactly what PhilIsHere was observing and what my suggestion is trying to fix:
EDIT
Nothing, it's a valid alternative.
It could even be worth to consider changing this to be Pi-hole's default.
But that may potentially break a lot of existing installations relying on /etc/hosts to be honored as a source for Pi-hole's DNS.
BIGEDIT: Oops I missed your last edit
But leave below comment as is.
So apply the no-hosts directive instead of degrading (by not using all the advantages that come with lo).
Thats the source for that 127.0.1.1 address.
You can always add your own additional records (EDIT: or aliases).
Thats not too difficult is it?
EDIT: I always found this bit particular with Pi-hole.
Most of the resolvers that I know dont read the hosts file (OOTB).
But I was told in the past it was to ensure not breaking legacy setups that still use the hosts file for importing other records.
Another argument to drop reading of that hosts file: OOTB the loopback addresses contained in them are useless for your other clients on the network.
Only time when its useful to have that 127.0.1.1 address registered in Pi-hole is if you would configure local /etc/resolv.conf to point to 127.0.0.1.
EDIT: Making the Pi-hole host the only potential client that would use that record.
Which it would not if configured the hosts file correctlly in which case DNS isnt addressed.
Of course localise-queries will do the rest
pi@ph5b:~ $ man dnsmasq
[..]
-y, --localise-queries
Return answers to DNS queries from /etc/hosts and --inter‐
face-name and --dynamic-host which depend on the interface
over which the query was received. If a name has more than
one address associated with it, and at least one of those
addresses is on the same subnet as the interface to which
the query was sent, then return only the address(es) on that
subnet. This allows for a server to have multiple addresses
in /etc/hosts corresponding to each of its interfaces, and
hosts will get the correct address based on which network
they are attached to. Currently this facility is limited to
IPv4.
