Can't get my devices to resolve through pihole

Expected Behaviour:

devices use pihole for DNS

Actual Behaviour:

no requests reported by pihole from anything but localhost

Debug Token:

I spent a bit of time trying to get my computers and devices to see the pi-hole I set up for testing purposes, and any DNS resolution they required failed out, after pointing them to the pi. The pi-hole's logs don't show requests coming in from any network devices; all devices are on the same subnet, port 53 isn't blocked, firewall on the pi itself isn't running, etc. The admin page is accessible via IP, but never at pi.hole.
What am I missing? Does FTL require more setup?

further information: I have a DHCP server already, so am not using the pihole for DHCP, just DNS.
pihole -g shows 81745 unique domains in gravity, all checks green.
Thanks in advance

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 pi.hole

nslookup pi.hole

connection timed out; no servers could be reached
same for pi.hole.

dig @ times out as well:
; <<>> DiG 9.16.1-Ubuntu <<>> @
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached

Please run the commands exactly as I posted and post the complete outputs.

$ nslookup pi.hole
;; connection timed out; no servers could be reached

$ nslookup pi.hole
;; connection timed out; no servers could be reached

Your Pi is not reachable in your network.
Can you ping

It's reachable, I'm SSHed in on a box that isn't using it for name resolution. it's headless, I just SSH into it.

Once I switch a device's DNS to it, edit it is still pingable with no packet loss from that device, but there's no name resolution.

PING ( 56 data bytes

64 bytes from icmp_seq=0 ttl=64 time=4.942 ms

64 bytes from icmp_seq=1 ttl=64 time=6.216 ms

64 bytes from icmp_seq=2 ttl=64 time=4.559 ms

64 bytes from icmp_seq=3 ttl=64 time=2.815 ms

64 bytes from icmp_seq=4 ttl=64 time=4.783 ms

64 bytes from icmp_seq=5 ttl=64 time=2.247 ms

64 bytes from icmp_seq=6 ttl=64 time=4.773 ms

64 bytes from icmp_seq=7 ttl=64 time=6.381 ms

64 bytes from icmp_seq=8 ttl=64 time=4.907 ms

64 bytes from icmp_seq=9 ttl=64 time=5.554 ms


--- ping statistics ---

10 packets transmitted, 10 packets received, 0.0% packet loss

round-trip min/avg/max/stddev = 2.247/4.718/6.381/1.247 ms

That nslookup was sent directly to Pi-hole's IPv4 address.
Did that nslookup register in your Pi-hole's debug log?

If it didn't, the DNS request never reached Pi-hole.

In that case, you should reverify whether you've configured your Pi-hole host machine's firewall to block port 53.

I can confirm it didn't appear in the log. As far as I know, firewall is disabled, I will recheck.

No firewall running, this box is behind my normal firewalls, so I hadn't set one up yet.

The interface in question has two inet6 addresses, which surprises me. My internal network is just running inet though, so I'd been ignoring it:
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether b8:27:eb:f6:0a:d7 brd ff:ff:ff:ff:ff:ff
inet brd scope global wlan0
valid_lft forever preferred_lft forever
inet6 fd16:3b9b:e002:1:35b1:ed04:e798:a3af/64 scope global mngtmpaddr noprefixroute dynamic
valid_lft 1777sec preferred_lft 1777sec
inet6 fe80::a790:927:dac2:6d4e/64 scope link
valid_lft forever preferred_lft forever

It's not unusual for a device to have a multitude of IPv6 addresses.
Besides, IPv6 isn't involved (yet), as that nslookup was directed specifically at Pi-hole's IPv4 address.

This leaves two other possible explanations:
a) another process on your Pi-hole machine snitches port 53 from Pi-hole
However, according to your debug log, this doesn't seem to be the case.
b) another networking device -your router or a dedicated firewall machine- blocks access to port 53 to your local Pi-hole.

Hm. that's what I was afraid of. I don't see firewall rules about port 53 on anything so far, or about that IP address. I didn't deliberately set it up, so now I'm working on the assumption it's something default-denied that I have to allow. I'm on an ASUS wireless router operating in AP mode, connected wired to my main router; the first device I tried this from was wireless-only (my phone), so I'm suspicious of the wireless router. Haven't found anything yet, unfortunately.

From what I can see, it's just pihole on :53:

sudo netstat -tulpn | grep ":53"
tcp        0      0    *               LISTEN      17733/pihole-FTL
tcp        0      0*               LISTEN      1499/unbound
tcp6       0      0 :::53                   :::*                    LISTEN      17733/pihole-FTL
udp        0      0    *                           17733/pihole-FTL
udp        0      0*                           1499/unbound
udp        0      0  *                           294/avahi-daemon: r
udp6       0      0 :::53                   :::*                                17733/pihole-FTL
udp6       0      0 :::5353                 :::*                                294/avahi-daemon: r

That confirms your debug log output's "Ports in use" section and my earlier remark:

So Pi-hole is the only process listening on port 53 on your machine, leaving other network devices as a probable cause.

Note that some ASUS routers are reported to always distribute their own IP address as DNS server via DHCP alongside any DNS servers you've configured through your router's DHCP settings.

While that would allow clients to by-pass Pi-hole via your router's IP, I'd expect your nslookup to return NXDOMAIN rather than timing out in that case.
That is to say that I'm not sure how that would contribute to explain your observation.
It probably could if your AP mode router would close a DNS loop with your main router (where your two routers keep forwarding DNS requests among themselves until time-out) - but that is a fair amount of speculation on my behalf.

You should consider consulting your router's documentation channels for information how it would handle DNS in AP mode, and if and how you can configure DNS in that mode.

Besides from said ASUS routers, I have seen reports in the past about Google Nest (and some other routers also from Google (my memory may be incorrect here...)) actively intercepting any port 53 traffic. Said user was never able to get it running but then they connected the devices behind a cheap simple network switch and everything started to work instantaneously. They replaced the Google router which was the only sensible thing because it was doing something your don't want as user.

hm. I have an entirely too heterogeneous network layout. It's also apparently possible that my cable modem is blocking 53, though how that would affect my internal network I'm unclear on.

Thanks for the help, I'm going to try moving it to physical ports around the place and see if I can isolate which device is the problem.

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