Clients unable to resolve Pi-Hole hostname

Expected Behaviour:

Using Pi-hole installed on Raspberry Pi OS as both a DNS and DHCP server, clients should be able to resolve the Pi-hole system's hostname. Both the hostname alone and FQDN should be resolvable.

Actual Behaviour:

Client systems are are unable to find the host. http://pi.hole/ resolves as expected. I see the hostname and proper IP address in the local.list file.

Debug Token:

https://tricorder.pi-hole.net/kf3uxaxhxs

Upon switching your DHCP server to Pi-hole, clients may hold on to their existing DHCP leases until they expire, i.e. they wouldn't use Pi-hole as DNS yet.
To enforce a DHCP lease renewal for a device, dis- and reconnect a client to yolur network, or power-cycle the device.

Also, if you didn't properly disable or range-limit your existing DHCP server yet, your clients may pick up DHCP leases from either DHCP-Server.

You can check whether a client would use Pi-hole as DNS by running the following command on that client:

nslookup pi.hole

Both the server and the answered address should show the same IP address, i.e. your Pi-hole's IP.

The former docker pihole instance has been shutdown, and the clients were restarted/had their DHCP leases renewed on the new pihole server. nslookup for pi.hole shows that the clients are requesting DNS resolutions from the new pihole server. But nslookups for the raspberry pi hostname come back unknown for both the hostname only and the FQDN.

After adding the FQDN to the Local DNS Records on the active pihole instance, then the system can be resolved. Removing the Local DNS Record after results in the system not being resolvable after a DNS flush.

Please provide an example for a failing hostname lookup, comprising the command you use and its full output.

Did a complete rebuild of the pi OS and pihole install last night to see if there was any difference. None unfortunately. Updated debug logs here: https://tricorder.pi-hole.net/23i1qluhlk

Here's the output from my main system when performing pings/nslookup:

C:\Users\Evan>ipconfig /all

Windows IP Configuration

   Host Name . . . . . . . . . . . . : GAMESTATION
   Primary Dns Suffix  . . . . . . . :
   Node Type . . . . . . . . . . . . : Hybrid
   IP Routing Enabled. . . . . . . . : No
   WINS Proxy Enabled. . . . . . . . : No
   DNS Suffix Search List. . . . . . : local.caldorian.com

Ethernet adapter Ethernet:

   Connection-specific DNS Suffix  . : local.caldorian.com
   Description . . . . . . . . . . . : Intel(R) Ethernet Connection (2) I218-V
   Physical Address. . . . . . . . . : XXXXXXXXXXXXX
   DHCP Enabled. . . . . . . . . . . : Yes
   Autoconfiguration Enabled . . . . : Yes
   Link-local IPv6 Address . . . . . : fe80::a0e8:863b:5b42:b985%6(Preferred)
   IPv4 Address. . . . . . . . . . . : 192.168.2.151(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Lease Obtained. . . . . . . . . . : October 20, 2020 10:20:18 PM
   Lease Expires . . . . . . . . . . : October 21, 2020 10:20:18 PM
   Default Gateway . . . . . . . . . : 192.168.2.1
   DHCP Server . . . . . . . . . . . : 192.168.2.2
   DHCPv6 IAID . . . . . . . . . . . : 52201260
   DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-21-C4-CA-F2-1C-87-2C-42-0C-F1
   DNS Servers . . . . . . . . . . . : 192.168.2.2
   NetBIOS over Tcpip. . . . . . . . : Enabled

C:\Users\Evan>nslookup pihole1
Server:  pihole1
Address:  192.168.2.2

Name:    pihole1
Address:  192.168.2.2


C:\Users\Evan>nslookup pihole1.local.caldorian.com
Server:  pihole1
Address:  192.168.2.2

*** No internal type for both IPv4 and IPv6 Addresses (A+AAAA) records available for pihole1.local.caldorian.com

C:\Users\Evan>ping pihole1
Ping request could not find host pihole1. Please check the name and try again.

C:\Users\Evan>ping pihole1.local.caldorian.com
Ping request could not find host pihole1.local.caldorian.com. Please check the name and try again.

C:\Users\Evan>ping 192.168.2.2

Pinging 192.168.2.2 with 32 bytes of data:
Reply from 192.168.2.2: bytes=32 time<1ms TTL=64
Reply from 192.168.2.2: bytes=32 time<1ms TTL=64
Reply from 192.168.2.2: bytes=32 time<1ms TTL=64
Reply from 192.168.2.2: bytes=32 time<1ms TTL=64

Ping statistics for 192.168.2.2:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 0ms, Average = 0ms

C:\Users\Evan>nslookup google.com
Server:  pihole1
Address:  192.168.2.2

Non-authoritative answer:
Name:    google.com
Addresses:  2607:f8b0:400b:801::200e
          172.217.1.14

C:\Users\Evan>nslookup pi.hole
Server:  pihole1
Address:  192.168.2.2

Name:    pi.hole
Address:  192.168.2.2


C:\Users\Evan>ping pi.hole

Pinging pi.hole [192.168.2.2] with 32 bytes of data:
Reply from 192.168.2.2: bytes=32 time<1ms TTL=64
Reply from 192.168.2.2: bytes=32 time<1ms TTL=64
Reply from 192.168.2.2: bytes=32 time<1ms TTL=64
Reply from 192.168.2.2: bytes=32 time<1ms TTL=64

Ping statistics for 192.168.2.2:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 0ms, Average = 0ms

C:\Users\Evan>

Add DNS records below:

http://pi.hole/admin/dns_records.php

But that's my point. The pihole's hostname already exists in local.list, so why isn't the pihole resolving it without having to add the extra DNS entry for the full FQDN to the local DNS records?

Because pihole1 is a different domain than pihole1.local.caldorian.com

1 Like

By default, Pi-hole's embdedded dnsmasq would only automatically add DNS records for a simple hostname expanded by the local search domain if a DHCP client would claim that hostname during DHCP lease negotiation.
Any manual DNS definitions (including CNAMEs, PTRs, SRVs, etc.) would be added as is, i.e without considering the search domain.

You may try to enable expand-hosts as a custom configuration option, but note that according to dnsmasq documentation, this won't work for all definition types, but for definitions in hosts files only.

Adding the DNS records explicitly is the safer way to provide resolution for local FQDNs, and it will also work when Pi-hole is not your DHCP server.

Thanks @Bucking_Horn. Seems that this is an issue related more to dnsmasq, and the fact that it doesn't automatically add the host system into it's DNS results by default. I still find it interesting that on my client system the hostname alone resolves for an NSLOOKUP (presumably because of the entry in local.list), but a ping request to it doesn't (I'm guessing because my client is natively appending the DNS suffix to the request).

I would still suggest that pi-hole could be updated to add a hostname.dhcp_dns_suffix entry to the local.list file when the dhcp service is activated.

It does so, but only for the very hostname the client claims for itself when acquiring a lease via DHCP.

To extend that to hosts file definitions, follow dnsmasq's documentation per my advice above.

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