It even appears completely fine to me?
The generation of the hostname has changed, too. Without further special setting, reverse lookups should show up as pi.hole for the local host. You can change this to the device's hostname by setting either
PIHOLE_PTR=HOSTNAME
in /etc/pihole/pihole-FTL.conf (see here) or even setting or even
PIHOLE_PTR=NONE
which makes adding a suitable record your responsibility (can be set, e.g., in /etc/hosts).
I have set
PIHOLE_PTR=HOSTNAME
however, the entry on the pihole query log still says localhost.
Is this issue localized to my system alone? All of this was not an issue at all before the recent update.
What is the output of
hostname
on your Pi-hole?
❯ hostname
hub
Then this entry likely comes from your /etc/hosts which always has higher priority than the other sources (RFC1123). I think this is correct and should have always been like this?
Try
dig +x 127.0.0.1 +short
on your Pi-hole. For other IP addresses of the machine (not listed in /etc/hosts) you should see hub.
I will add a new option PIHOLE_PTR=HOSTNAMEFQDN that will add the local suffix.
/etc/hosts does not have any mention of hub. Here are the contents of that file:
127.0.0.1 localhost localhost.localdomain
# The following lines are desirable for IPv6 capable hosts
::1 localhost6.localdomain6 localhost6
::1 localhost ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
ff02::3 ip6-allhosts
Here's the output of dig +x 127.0.0.1 +short
❯ dig +x 127.0.0.1 +short
Invalid option: +x
Usage: dig [@global-server] [domain] [q-type] [q-class] {q-opt}
{global-d-opt} host [@local-server] {local-d-opt}
[ host [@local-server] {local-d-opt} [...]]
Use "dig -h" (or "dig -h | more") for complete list of options
If I do dig hub +short, I get:
❯ dig hub +short
127.0.0.1
I will add a new option
PIHOLE_PTR=HOSTNAMEFQDNthat will add the local suffix.
Thanks!
Sorry, it should have been -x not +x.
Yeah, that's why I'm asking myself if 127.0.0.1 should at all be returning hub as name.
Ran the updated command, got the following as result:
❯ dig -x 127.0.0.1 +short
localhost.
So what you see is what is expected and there is no bug IMO. Pi-hole has never returned your hostname for the loopback addresses 127.0.0.1 and ::1.
But I am certain that within the pihole UI, queries made by the host itself were showing up as hub.synapse.lan and now show up as localhost. Agree that it is not a major issue as things work. I am just trying to understand what changed to cause the new bahavior.
Also, I am on the dev branch. How would I know when to checkout master again?
Let me briefly explain what changed and hopefully we find out if we're really talking about the same thing.
Pi-hole always served the same IP address for pi.hole, say 192.168.0.10. This was also the only address that responded with the name pi.hole when doing a reverse lookup. This had a number of drawbacks especially notable on devices with multiple interfaces. These don't have to be physical interfaces, it could also be a Pi-hole that is connected to any kind of VPN (may it be the server or a client). If requesting pi.hole over the VPN, the Pi-hole would have replied with the one IP address it knew, however, this address would not necessarily have been reachable through the VPN leading to a timeout at the requester.
When we switched to interface-aware replies in FTL v5.9 (last month), this changed. Pi-hole does now reply with the most suitable address when being asked for pi.hole or the hostname. In the example above, this would be the IP address of the VPN interface instead of 192.168.0.10.
The same applies to name lookups: before v5.9, Pi-hole would only have responded with pi.hole for the one address defined in its config. Now, we reply with pi.hole (or the hostname if PIHOLE_PTR says so) to all valid addresses of local interfaces except the loopback addresses 127.0.0.1 and ::1. I firmly believe that this has always been like that.
There is one noteworthy exception to this that are internally generated DNSSEC queries always showing up as done by client pi.hole.
The only way I could imagine Pi-hole showing your hostname as client is if you are using an address of any local interface (e.g., 192.168.0.10) and not the loopback address 127.0.0.1.
Is your Pi-hole using itself as resolver (what is the content of your /etc/resolv.conf ?) or are you using some other resolver?
When we release the next version of Pi-hole. This shows up in the announcements on the top of the start page of this forum and also on Blog – Pi-hole .
The feature PR can be tracked here:
Here are the contents of /etc/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
# 127.0.0.53 is the systemd-resolved stub resolver.
# run "systemd-resolve --status" to see details about the actual nameservers.
nameserver 127.0.0.1
I've not added that entry by hand.
As suggested by the last line that file, if I run systemd-resolve --status, I get:
❯ systemd-resolve --status
Failed to get global data: Unit dbus-org.freedesktop.resolve1.service not found.
Thanks a lot for all the back and forth, I really appreciate it!
This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.