Pi-hole hostname resolves to 127.0.1.1 from a client

Help Community Help
1

Hi all, I could use some help trying to figure out below issue.
I have a RaspiOS Buster Pi-hole setup running on a dedicated Raspi model 1B with Unbound configured upstream and Pi-hole doing DHCPv4 for my network.

The problem is, the Pi-hole hostname is resolved to a localhost address 127.0.1.1 and not to the actual address when doing lookups from a client:

C:\>nslookup ph5a
Server:  ph5a
Address:  10.0.0.2

Name:    ph5a.dehakkelaar.nl
Address:  127.0.1.1

The Pi-hole host is configured as followed:

pi@ph5a:~ $ cat /etc/hostname
ph5a

pi@ph5a:~ $ cat /etc/dhcpcd.conf
[..]
interface eth0
  static ip_address=10.0.0.2/24
  static routers=10.0.0.1
  static domain_name=dehakkelaar.nl
  static domain_name_servers=10.0.0.1

pi@ph5a:~ $ cat /etc/hosts
127.0.0.1       localhost
::1             localhost ip6-localhost ip6-loopback
ff02::1         ip6-allnodes
ff02::2         ip6-allrouters

127.0.1.1       ph5a.dehakkelaar.nl  ph5a

And seems to work as expected:

pi@ph5a:~ $ hostname
ph5a

pi@ph5a:~ $ hostname -f
ph5a.dehakkelaar.nl

pi@ph5a:~ $ dnsdomainname
dehakkelaar.nl

What I figured out is that the ph5a name in below file will be ignored if it isn't a FQDN:

pi@ph5a:~ $ cat /etc/pihole/local.list
10.0.0.2 ph5a
10.0.0.2 pi.hole

And the localise-queries logic in dnsmasq will produce the 127.0.1.1 IP from the /etc/hosts file instead of the preferred local.list entry.

I believe below code is related and it prefers content from the /etc/hostname file over that of the hostname -f output:

Do any of you have the same with only the short name (not a FQDN one) reflected in the /etc/hostname file?
I havn't checked/cant recollect but isnt a fresh RaspiOS OOTB also configured with only a short hostname "raspberrypi" or something?
I know I can configure the hostname to be a FQDN one but shouldn't above also work?

2

First, it is Windows' nslookup that expands your hostname from ph5a to ph5a.dehakkelaar.nl by attaching your local search suffix dehakkelaar.nl.

Judging by the information you supplied, the only available resolution then is 127.0.1.1 as found in /etc/hosts, so it seems Pi-hole provides the correct answer.
Removing that line from your /etc/hosts should resolve your issue.

I have also checked all of my Pi-hole instances, and none of them contains any FQDN for the local hostname in /etc/hosts.
Changing the local hostname via hostnamectl or raspi-config did not alter /etc/hosts, and neither did a follow-up pihole -r.

This gives rise to the question how those local hostname definitions (and especially the FQDN) would have made it into your hosts file?

1 Like
3

That was it, when I remove the FQDN in the hosts file:

pi@ph5a:~ $ cat /etc/hosts
127.0.0.1       localhost
::1             localhost ip6-localhost ip6-loopback
ff02::1         ip6-allnodes
ff02::2         ip6-allrouters

127.0.1.1       ph5a

And rebuild the local.list file with a gravity run to be sure, I get the expected result on a client:

dehakkelaar@laptop:~$ nslookup  ph5a
Server:         127.0.0.1
Address:        127.0.0.1#53

Name:   ph5a
Address: 10.0.0.2

Its just that I am used to supplying all the names (short, long etc) on that one single line in the hosts file eg:

127.0.1.1 ph5a.dehakkelaar.nl ph5a.dehakkelaar ph5a

And before, with other software, didnt cause any issues.
I believe it used to be the recommend way but maybe things have changed?

But after ditching the FQDN in the hosts file, I did lose the ability to read out some info with below:

pi@ph5a:~ $ hostname
ph5a

pi@ph5a:~ $ hostname -f
ph5a

pi@ph5a:~ $ dnsdomainname
pi@ph5a:~ $

Compared to before removing the FQDN from the hosts file:

So it feels like something is still not quite right yet?
I'm suspecting that if a FQDN entry is available to dnsmasq, like before in my hosts file, it prefers that IP over the short name stored in the local.list file (I know the domain suffix is appended to the query).
I have a hard time testing things currently because my sandbox Pi was given away as a present and a replacement Pi is on the wish list.
So I'll leave it as is for the moment and dig a bit deeper when the replacement arrives.
Testing on the live setup is not appreciated by my fellow home dwellers :wink:

EDIT: added some

4

nslookup ph5a will attach any suffix to a search. nslookup ph5a. is the format if you don't want the query to be xpanded. The first format will try the name given and if it's not found then it will try again with the search name attached to the query name.

1 Like
5

Yes but even when the domain suffix is added, the query for ph5a.dehakkelaar.nl should never resolve to 127.0.1.1 for a client should it?

I was never a fan of letting dnsmasq read the hosts file which is intended for the own host and not for sharing name resolution with others on the net.
If I configure everything like before, and change the local.list entry into a FQDN one, it also fixes the issue.
One affects the other and I need to RTFM I guess :wink:

6

Using 127.0.1.1 specifically seems to have been necessary in the past to avoid a potential glitch with certain software.
However, for "a system with a permanent IP address, that permanent IP address should be used here instead of 127.0.1.1" (quoted from Debian docs on hostname resolution).

1 Like
7

Yeah that makes sense.
With the many Redhat/CentOS instances I installed in the past, I never experienced this line using the loopback.
Only when installing Raspbian I noticed this.
I do recall instances with clustering where traffic would get looped back destined for the own hostname as its much faster as via ethernet and your not broadcasting (EDIT: plus with ethernet, if interface is down/unplugged, there is no trafic).
Below is from a RaspiOS image I mounted:

dehakkelaar@laptop:~$ cat /mnt/tmp/etc/hosts
127.0.0.1       localhost
::1             localhost ip6-localhost ip6-loopback
ff02::1         ip6-allnodes
ff02::2         ip6-allrouters

127.0.1.1               raspberrypi

I configured everything like below now:

pi@ph5a:~ $ cat /etc/hostname
ph5a

pi@ph5a:~ $ cat /etc/hosts
127.0.0.1       localhost
::1             localhost ip6-localhost ip6-loopback
ff02::1         ip6-allnodes
ff02::2         ip6-allrouters

10.0.0.2        ph5a.dehakkelaar.nl  ph5a

pi@ph5a:~ $ cat /etc/dhcpcd.conf
[..]
interface eth0
  static ip_address=10.0.0.2/24
  static routers=10.0.0.1
  static domain_name=dehakkelaar.nl
  static domain_name_servers=10.0.0.1

Which reports just fine:

pi@ph5a:~ $ hostname
ph5a

pi@ph5a:~ $ hostname -f
ph5a.dehakkelaar.nl

pi@ph5a:~ $ dnsdomainname
dehakkelaar.nl

And resolves properly on a client now:

dehakkelaar@laptop:~$ host ph5a
ph5a.dehakkelaar.nl has address 10.0.0.2

Thanks all for clearing that one up!

EDIT: Ow ps. this makes the entry in the local.list file a bit redundant or not?
That one tries to get the FQDN from the /etc/hostname file or if fails, from hostname -f (from the github code snippet I posted previously).

8

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

9

I broke gravity anyway as I prefer loopback :wink:
.
.
.

EDIT: Darn, it was easier than that :smiley:
I just had to add the no-hosts directive to dnsmasq.d and I got the correct reply returned from a client 10.0.0.4 and 127.0.1.1 for local lookups.
Breaking gravity wasnt necessary.

pi@ph5b:~ $ host ph5b ph5b
Using domain server:
Name: ph5b
Address: 127.0.1.1#53
Aliases:

ph5b.home.dehakkelaar.nl has address 10.0.0.4