The issue I am facing:
DNS not resolving when pihole DNS server is set onto hosts. Queries are being logged on the Web interface, but no resolution. Additionally, DHCP is not handing out addresses to hosts.
Details about my system:
PiHole Servers running on Ubuntu 20.0.4 LTS (dual-booted on MacOS)
DDWRT local router being used
What I have changed since installing Pi-hole:
Clients with statically assigned IPs are able to ping PiHole server and vice versa. Router set to DHCP forward to PiHole server address (DHCP Server disabled on local router). Local DNS on router also reflects PiHole IP. Firewall on server allow incoming/outgoing tcp/udp traffic on ports 53 and 67. /etc/resolv.conf reflects piHole server IP.
Please upload a debug log and post just the token that is generated after the log is uploaded by running the following command from the Pi-hole host terminal:
Your Debug Log shows that DNS resolution fails when trying to use any of your Pi-hole hosts IPv4 addresses:
*** [ DIAGNOSING ]: Name resolution (IPv4) using a random blocked domain and a known ad-serving domain
[✓] moferta.xyz is 0.0.0.0 on lo (127.0.0.1)
[✓] No IPv4 address available on enp2s0f0
[✗] Failed to resolve moferta.xyz on wlp3s0 (192.168.1.20)
[✗] Failed to resolve moferta.xyz on as0t0 (172.27.224.1)
[✗] Failed to resolve moferta.xyz on as0t1 (172.27.226.1)
[✗] Failed to resolve moferta.xyz on as0t2 (172.27.228.1)
[✗] Failed to resolve moferta.xyz on as0t3 (172.27.230.1)
[✗] Failed to resolve moferta.xyz on as0t4 (172.27.232.1)
[✗] Failed to resolve moferta.xyz on as0t5 (172.27.234.1)
[✗] Failed to resolve moferta.xyz on as0t6 (172.27.236.1)
[✗] Failed to resolve moferta.xyz on as0t7 (172.27.238.1)
[✓] doubleclick.com is 142.250.186.78 via a remote, public DNS server (8.8.8.8)
This would suggest something is blocking requests - most commonly, the host machine's firewall isn't configured to allow for Pi-hole's required ports.
In addition, there are multiple network interfaces attached to your host, though there seems to be just one physical interface. Presumably, you are running several VLANs or VPNs?
Pi-hole's DHCP server supports flat networks only.
If you want to provide DHCP services for all of your VLANs/VPNs, you'd have to configure that manually, by means of custom dnsmasq configuration files.
I am running Ubuntu dual-booted on a MacOS, but I wouldn't imagine that would cause a firewall issue - yeah? I am not using any of the other interfaces, only wlp3s0 and enp2s0f0 for wired connections. I could live without piHole's DHCP servers though; I configured it for DHCP as a backwards-solution to the DNS issue.
Copy - router is now acting as my DHCP server. I have no idea where those interfaces are from - they were present when I installed Ubuntu. The wlp3s0 is for wifi and the enp2s0f0 is for wired connections.
jimi@jimi-MacBookPro:~$ nslookup pi.hole
;; connection timed out; no servers could be reached
jimi@jimi-MacBookPro:~$ nslookup flurry.com
;; connection timed out; no servers could be reached
jimi@jimi-MacBookPro:~$ ping 192.168.1.20
PING 192.168.1.20 (192.168.1.20) 56(84) bytes of data.
64 bytes from 192.168.1.20: icmp_seq=1 ttl=64 time=0.121 ms
64 bytes from 192.168.1.20: icmp_seq=2 ttl=64 time=0.121 ms
64 bytes from 192.168.1.20: icmp_seq=3 ttl=64 time=0.108 ms
^C
--- 192.168.1.20 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2042ms
rtt min/avg/max/mdev = 0.108/0.116/0.121/0.006 ms
Would it help to see my router settings as well? Additionally, I believe the as0t[n] interfaces are tunnel interfaces created by my OpenVPN server which is running on this same machine.
If no firewall is blocking DNS requests (either on the Pi-hole host or on the requesting client), then Pi-hole might not be configured for the interface the DNS request is received on.
You could try to switch Pi-hole's Interface listening behaviour to one of its Listen on all... options via Settings | DNS.
Uninstalled pihole then reinstalled and manually set pihole as DNS server on host devices instead of router - pihole now resolving DNS and blocking traffic as expected