EDIT:
I've been using your debug log at https://tricorder.pi-hole.net/UNs1ypoV/ as provided by you in your GitHub issue.
There's something off with your routing.
Your router's DHCP server is pushing 192.168.0.249
as your network's router/gateway:
*** [ DIAGNOSING ]: Discovering active DHCP servers (takes 10 seconds)
Scanning all your interfaces for DHCP servers
* Received 548 bytes from eth0:192.168.0.249
Offered IP address: 192.168.0.34
DHCP options:
Message type: DHCPOFFER (2)
router: 192.168.0.249
--- end of options ---
Commonly, routers would tend to assign the first (.1
) or last (.254
) avallable IP address to themselves. Yours using a .249
would seem unusual (but not at all harmful).
But your routing table looks strange:
*** [ DIAGNOSING ]: Network routing table
default via 192.168.0.249 dev eth0 onlink
default via 192.168.0.253 dev eth0 src 192.168.0.250 metric 202
169.254.0.0/16 dev eth0 scope link metric 1000
192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.250 metric 100
192.168.0.0/24 dev eth0 proto dhcp scope link src 192.168.0.250 metric 202
IPv4 link-locals (169.254.0.0/16
) are expected to show up only on devices with no means of address assignment, but your device clearly has been able to assign an IP address to its eth0
network interface. That said, I don't think that should cause any issues, even if it's unexpected.
What could cause issues is that your routing table shows two default routes for the same network interface (eth0
), one via your .249
and one via .253
.
While .249
seems to match the actual IP of your router, the corresponding route seems to have been forcefully added to the routing table, as suggested by onlink
(which would prompt your OS to skip connectivity tests for that route and add it to the routing table regardless).
Your debug log would further suggest that your router (perhaps an Asus ROG GT-AC5300?) would indeed have resided at .253
at some stage in the past, at least when Pi-hole was your DHCP server:
*** [ DIAGNOSING ]: contents of /etc/dnsmasq.d
-rw-r--r-- 1 root root 2.7K May 14 14:17 /etc/dnsmasq.d/04-pihole-static-dhcp.conf
dhcp-host=xx:xx:xx:xx:xx:xx,192.168.0.253,GT-AC5300
Incorrect routing could also explain why your debug log shows your Pi-hole host machine to be unable to contact public DNS servers:
*** [ DIAGNOSING ]: Operating system
[i] dig return code: 9
[i] dig response: ;; connection timed out; no servers could be reached
*** [ DIAGNOSING ]: Name resolution (IPv4) using a random blocked domain and a known ad-serving domain
[✓] ads2.hsoub.com is 0.0.0.0 on lo (127.0.0.1)
[✓] ads2.hsoub.com is 0.0.0.0 on eth0 (192.168.0.250)
[✗] Failed to resolve doubleclick.com via a remote, public DNS server (8.8.8.8)
*** [ DIAGNOSING ]: Name resolution (IPv6) using a random blocked domain and a known ad-serving domain
[✓] www.informacja2273.site is :: on lo (::1)
[✓] www.informacja2273.site is :: on eth0 (fe80::215:18ff:fe01:8131)
[✗] Failed to resolve doubleclick.com via a remote, public DNS server (2001:4860:4860::8888)
Did you change your router's configuration lately, or introduce some change in your network equipment, like adding or reconfiguring additional network equipment (APs, switches, routers,...)?