Pihole not resolving it's own hostname

Expected Behaviour:

PiHole should resolve its own hostname to an IP. Running on Ubuntu 20.04

Actual Behaviour:

My pihole host is called "hub." When I ping this machine from any other host on my network or from the host itself, I get the following error:
ping: cannot resolve hub: Unknown host

As a result, I cannot address any services running on this machine via hostname. This was not happening before. All other hosts on the network resolve just fine when pinged either with the short name, e.g. ping router or with the full hostname: ping router.synapse.lan

pihole is not delivering DHCP services. DHCP comes from the router (pfSense).

Debug Token:

https://tricorder.pi-hole.net/25nloh7d/

From a client that you believe should be connected to the Pi-Hole for DNS, from the command prompt or terminal on that client (and not via ssh or Putty to the Pi), what is the output of

nslookup hub

Then, towards the end of the dnsmasq log at /var/log/pihole.log, please find and post the transactions involved. There will be a query for hub, and a reply.

When running nslookup hub from another host (with IP 192.168.7.24), I get:

Server:		192.168.7.2
Address:	192.168.7.2#53

Non-authoritative answer:
*** Can't find hub: No answer

The corresponding entry in /var/log/pihole.log is:

Oct  1 16:41:48 dnsmasq[881]: query[A] hub.synapse.lan from 192.168.7.24`
Oct  1 16:41:48 dnsmasq[881]: Pi-hole hostname hub.synapse.lan is Pi-hole hostname

The "can't find hub" response is strange because on the same host, everything works just fine. Which means it is able to find hub (the pihole) to resolve other DNS queries!

>> nslookup cnn.com
Server:		192.168.7.2
Address:	192.168.7.2#53

Non-authoritative answer:
Name:	cnn.com
Address: 151.101.193.67
Name:	cnn.com
Address: 151.101.65.67
Name:	cnn.com
Address: 151.101.1.67
Name:	cnn.com
Address: 151.101.129.67

The requesting client is not asking for hub. It has appended your domain name onto the request, which makes this a different domain.

*** [ 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 331 bytes from enp0s31f6:192.168.7.1
     Offered IP address: 192.168.7.2
     Server IP address: N/A
     Relay-agent IP address: N/A
     BOOTP server: (empty)
     BOOTP file: (empty)
     DHCP options:
      Message type: DHCPOFFER (2)
      server-identifier: 192.168.7.1
      lease-time: 7200 ( 2h )
      netmask: 255.255.255.0
      router: 192.168.7.1
      dns-server: 192.168.7.2
      hostname: "hub"
      ntp-server: 193.252.223.86
      ntp-server: 163.172.150.183
      ntp-server: 92.243.6.5
      ntp-server: 37.187.20.28
      ntp-server: 162.159.200.123
      ntp-server: 162.159.200.1
         domain-name: "synapse.lan"
      --- end of options ---

I get the same response when I query the full hostname

nslookup hub.synapse.lan
Server:		192.168.7.2
Address:	192.168.7.2#53

Non-authoritative answer:
*** Can't find hub.synapse.lan: No answer

corresponding entry in the log:

Oct  1 17:07:15 dnsmasq[881]: query[A] hub.synapse.lan from 192.168.7.24
Oct  1 17:07:15 dnsmasq[881]: Pi-hole hostname hub.synapse.lan is Pi-hole hostname

Doing a nslookup on another host works just fine.

nslookup router.synapse.lan
Server:		192.168.7.2
Address:	192.168.7.2#53

Name:	router.synapse.lan
Address: 192.168.7.1

That's strange. It should return the correct IP and should log something like

Oct  1 20:56:54 dnsmasq[31964]: query[A] pi.hole from 10.0.1.39
Oct  1 20:56:54 dnsmasq[31964]: Pi-hole hostname pi.hole is 10.0.1.5

Changes to the hostname resolutions have been made recently here and here.

As the hostname is known to FTL, it's strange that no IP is returned for that interface.

There was a bug with hostname resolution, but this was fixed yesterday. You're running the lastest version already

*** [ DIAGNOSING ]: FTL version
[✓] FTL: v5.10.2 (https://discourse.pi-hole.net/t/how-do-i-update-pi-hole/249)

Please enable DEBUG_QUERIES and DEBUG_NETWORKING in pihole-FTL.conf, restart Pi-hole and retry the query. Please post the relevant output of /var/log/pihole-FTL.log

Followed the instructions:

  1. enabled DEBUG_QUERIES and DEBUG_NETWORKING
  2. restarted pihole
  3. tried nslookup hub.synapse.lan

result:

Oct  1 23:11:38 dnsmasq[130486]: query[A] hub.synapse.lan from 192.168.7.24
Oct  1 23:11:38 dnsmasq[130486]: Pi-hole hostname hub.synapse.lan is Pi-hole hostname

If it helps, I was also seeing the behavior explained in this bug: Pihole DNS returns 127.0.1.1 when querying its FQDN (e.g. hostname.lan) · Issue #1168 · pi-hole/FTL · GitHub

I ended up adding the following entries to /etc/hosts in order to fix:
192.168.7.2 hub.synapse.lan hub

Won't claim that I totally know what I am doing here but without that entry in the hosts file, I could not even ping hub while on the same host!

>> ping hub.synapse.lan                                                                                          
ping: hub.synapse.lan: No address associated with hostname

Could you please remove

again. And run the nslookup from above again and share the output of

(Note: it's a different log file!)

Steps taken:

  1. removed 192.168.7.2 hub.synapse.lan hub from /etc/hosts. The content of that file are now as below. Note: I don't use ipv6.
127.0.0.1       localhost.localdomain localhost

# 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
  1. The contents of /etc/hostname is as follows:
    hub

  2. ran nslookup discord.com; nslookup hub; nslookup hub.synapse.lan. I did this so I could grep for "discord.com" in the noise and locate the log entry easily. output below:

9791 [2021-10-02 10:40:21.480 232327M] **** new UDP IPv4 query[A] query "discord.com" from :192.168.7.24#49803 (ID 829, FTL 20103, src/dnsmasq/forward.c:1591)
9792 [2021-10-02 10:40:21.480 232327M] discord.com is known as not to be blocked
9793 [2021-10-02 10:40:21.480 232327M] **** forwarded discord.com to 192.168.7.1#53 (ID 829, src/dnsmasq/forward.c:522)
9794 [2021-10-02 10:40:21.481 232327M] **** got upstream reply from 192.168.7.1#53: discord.com is 162.159.138.232 (ID 829, src/dnsmasq/rfc1035.c:892)
9795 [2021-10-02 10:40:21.481 232327M] Set reply to IP (4) in src/dnsmasq_interface.c:1972
9796 [2021-10-02 10:40:21.481 232327M] **** got upstream reply from 192.168.7.1#53: discord.com is 162.159.128.233 (ID 829, src/dnsmasq/rfc1035.c:892)
9797 [2021-10-02 10:40:21.481 232327M] **** got upstream reply from 192.168.7.1#53: discord.com is 162.159.137.232 (ID 829, src/dnsmasq/rfc1035.c:892)
9798 [2021-10-02 10:40:21.481 232327M] **** got upstream reply from 192.168.7.1#53: discord.com is 162.159.135.232 (ID 829, src/dnsmasq/rfc1035.c:892)
9799 [2021-10-02 10:40:21.481 232327M] **** got upstream reply from 192.168.7.1#53: discord.com is 162.159.136.232 (ID 829, src/dnsmasq/rfc1035.c:892)
9800 [2021-10-02 10:40:21.526 232327M] Replying to hub.synapse.lan with NODATA due to missing iface address
9801 [2021-10-02 10:40:21.527 232327M] FTL_reply(): Query 830 has not been found
9802 [2021-10-02 10:40:21.576 232327M] Replying to hub.synapse.lan with NODATA due to missing iface address
9803 [2021-10-02 10:40:21.576 232327M] FTL_reply(): Query 831 has not been found

Issue is due to: NODATA due to missing iface address

Here are the contents of /etc/pihole/setupVars.conf:

WEBPASSWORD=xxx
CONDITIONAL_FORWARDING=false
TEMPERATUREUNIT=C
BLOCKING_ENABLED=true
PIHOLE_INTERFACE=enp0s31f6
IPV4_ADDRESS=192.168.7.2/24
IPV6_ADDRESS=
QUERY_LOGGING=true
INSTALL_WEB_SERVER=false
INSTALL_WEB_INTERFACE=true
LIGHTTPD_ENABLED=false
CACHE_SIZE=10000
ADMIN_EMAIL=xxx
WEBUIBOXEDLAYOUT=boxed
WEBTHEME=default-auto
DNSMASQ_LISTENING=single
PIHOLE_DNS_1=192.168.7.1#53
DNS_FQDN_REQUIRED=true
DNS_BOGUS_PRIV=true
DNSSEC=false
REV_SERVER=true
REV_SERVER_CIDR=192.168.7.0/24
REV_SERVER_TARGET=192.168.7.1
REV_SERVER_DOMAIN=synapse.lan

and the contents of /etc/pihole/pihole-FTL.conf

BLOCKINGMODE=NULL
CNAME_DEEP_INSPECT=true
REFRESH_HOSTNAMES=IPV4
DBIMPORT=yes
DBINTERVAL=5.0
MAXLOGAGE=12.0
IGNORE_LOCALHOST=no
AAAA_QUERY_ANALYSIS=no
RESOLVE_IPV6=no
RESOLVE_IPV4=yes
MAXDBDAYS=15
ANALYZE_ONLY_A_AND_AAAA=true
PRIVACYLEVEL=0
DEBUG_QUERIES=true
DEBUG_NETWORKING=true
1 Like

I tried something and it seems to work. Instead of picking a specific interface under "Interface listening behavior" I picked "Listen on all interfaces" and that seems to have fixed all but one issue. Now, when I try ping hub when I am on the host hub, I get:

ping hub                                                                                                          
ping: hub: No address associated with hostname

but pinging the full hostname works:

ping hub.synapse.lan                                                                                                  
PING hub.synapse.lan (192.168.7.2) 56(84) bytes of data.
64 bytes from pi.hole (192.168.7.2): icmp_seq=1 ttl=64 time=0.056 ms

pinging hub or hub.synapse.lan from other hosts works fine. So the issue is local to the host hub.

Also noticed that the entry for hub in the "query" section of the pihole UI now shows localhost.localdomain vs hub or hub.synapse.lan
All other local hosts appear fine with their FQDN. (e.g. router.synapse.lan)

1 Like

Thanks for your reply!

The devs already work on a fix for this. Please continue reading here:
https://github.com/pi-hole/FTL/issues/1191#issuecomment-932724447

There is also already a special branch, which you might want to try.

I installed the test branch using pihole checkout ftl tweak/iface_detection

now, when I do ping hub.synapse.lan, i get:

❯ ping hub.synapse.lan                                                                                                  
PING hub.synapse.lan (192.168.7.2) 56(84) bytes of data.
64 bytes from pi.hole (192.168.7.2): icmp_seq=1 ttl=64 time=0.058 ms

however, pinging the short name hub still produces the old result:

❯ ping hub
ping: hub: No address associated with hostname

I am issuing these commands on the host hub directly. pinging the short name hub from any other host on my network works just fine.

❯ ping hub
PING hub.synapse.lan (192.168.7.2): 56 data bytes
64 bytes from 192.168.7.2: icmp_seq=0 ttl=64 time=1.716 ms
64 bytes from 192.168.7.2: icmp_seq=1 ttl=64 time=3.931 ms
^C
--- hub.synapse.lan ping statistics ---
2 packets transmitted, 2 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 1.716/2.824/3.931/1.107 ms

Please include the relevant part of pihole-FTL.log

Sorry about that. Here you go:
Command issued: nslookup hub
response received:

❯ nslookup hub                                                                                                          
Server:		127.0.0.1
Address:	127.0.0.1#53

Non-authoritative answer:
*** Can't find hub: No answer

relevant log entry from pihole-FTL.log:

[2021-10-02 14:49:43.778 75866M] Replying to hub with NODATA due to missing iface address
[2021-10-02 14:49:43.779 75866M] FTL_reply(): Query 1642 has not been found
[2021-10-02 14:49:43.779 75866M] Replying to hub with NODATA due to missing iface address
[2021-10-02 14:49:43.779 75866M] FTL_reply(): Query 1643 has not been found

I had a look at your debug log again and you have one file here:

-rw-r--r-- 1 root root 95 Jun 10  2019 /etc/dnsmasq.d/ubuntu-fan
   bind-interfaces
   except-interface=fan-*

Did you set it on purpose? The same advice as given here applies

I didn't set any of that. Its either default or Ubuntu updates. I should delete that file? I do run docker on my system and "fan networking" seems to be a thing:

Yes. I don't see any bad things that could happen when you remove this. You could also try my fix proposed here with the checkout command (before deleting the file):

https://github.com/pi-hole/FTL/issues/1191#issuecomment-932740036

You could also try my fix proposed here with the checkout command (before deleting the file)

If you mean this command, pihole checkout ftl tweak/iface_detection, then I have already done that (as mentioned in the thread above).

Ah, yes, sorry. I wanted to say: Please do it again.
The branch was updated and either another checkout or an update will grab the changes.

ok, updated. Here's what I am seeing now. Pinging hub results in:

❯ ping hub                                                                                                              
PING hub (127.0.0.1) 56(84) bytes of data.
64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=1 ttl=64 time=0.056 ms

So that's better than host not found.

Also, the issue that I reported before regarding the appearance of queries from this host (on which pihole is running) still remain. Copied the issue below for easy access.