ip -br -4 address show scope global
enp2s0 UP 192.168.10.2/24
I do not run AV software on my MacBook Air -- not recommended anymore. However, I do use a VPN client. Disconnecting it and running the command and gives the same results:
nslookup -class=chaos -type=txt version.bind 192.168.10.2
Server: 192.168.10.2
Address: 192.168.10.2#53
Non-authoritative answer:
version.bind text = "Q9-P-7.6"
Authoritative answers can be found from:
Do you have another client that you can run that version.bind lookup from?
Can be Windows, Linux and oc MacOS.
So to distinct if its client or network related.
EDIT: Oh and can you run that same lookup on the Pi-hole host as well and share the output pls?
Right now, I can run it from the Pi Hole itself, or from another Linux box with a static IP outside the DHCP pool. Don't have a Windows machine at the moment.
Pi Hole:
nslookup -class=chaos -type=txt version.bind 192.168.10.2
Server: 192.168.10.2
Address: 192.168.10.2#53
version.bind text = "dnsmasq-pi-hole-v2.90+1"
Tydirium [static IP 192.168.10.3]
nslookup -class=chaos -type=txt version.bind 192.168.10.2
Server: 192.168.10.2
Address: 192.168.10.2#53
version.bind text = "dnsmasq-pi-hole-v2.90+1"
As suspected, your nslookup results demonstrate that it isn't Pi-hole answering DNS requests (at least for the client that ran those nslookups), and above supplementary bind.version result indicates that something in your network is intercepting DNS requests and redirecting them to Quad9's DNS servers.
This may also have impacted your earlier nslookups for local names directed at your router:
If those would have been redirected to Quad9 as well, then of course Quad9 wouldn't know about your local domains.
You'd have to address this before you consider any configuration changes in Pi-hole, as it would be impossible to observe any effect as long as Pi-hole is being by-passed.
As your most recent nslookup from 192.168.10.3 (Tydirium) returns the expected dnsmasq-pi-hole-v2.90+1, that would suggest that interception is at least not affecting your entire network, but is confirmed for just one client so far.
You may want to run those version.bind lookups from a few other clients as well, and look out whether redirection may happen only on certain subnets (like guest networks or VLANs) or connection types (wireless vs. LAN cable).
If it turns out that it's just that one client that's intercepted:
VPN client software commonly forcefully redirects DNS, so you should verify that it's not VPN software on your client interfering here.
Side note: As this turns out to be an entirely different issue than your original topic's question, I'm probably going to split related posts into a new topic of its own, so they can find separate solutions.
Right now, after having dealing with this for five months and gotten nowhere, I am about two millimeters away from formatting the hard drive and starting all over, beginning with a clean install of Ubuntu. If anyone can think of any reason I shouldn't do so, please let me know... in the meantime, I have to go to work. Back this evening.
Reinstalling Pi-hole won't help.
Your Pi-hole is being by-passed, at least by one client, and that client's DNS requests are intercepted and redirected to Quad9 instead.
You'd have to find the piece of software that is forcing that redirect.
Likely candidates are antivirus DNS features or VPN software running on an affected client, or a router firewall forcing DNS to its own choice of DNS servers on a network level, either for your entire network or specific subnets.
The version.bind lookups may help you narrowing down potential causes.
Asus RT AX-55. Not flashed. It does look like the problem is in there somewhere, so I spent some time experimenting a bit with its settings, removing all references to Quad9 and pointing everything at the Pi, removing the domain name (both on the router and on the Pi Hole), forgetting both WiFi networks on my MacBook Air and re-adding them, manually configuring DNS to point only at 192.168.10.2, moving the MBA’s IP outside of the DHCP pool… same result every time, DNS responses coming from Quad 9. I didn’t have enough time to try turning off WiFi and using Ethernet instead. I’ll see whether I can find the right kind of dongle at work today.
For Pete’s sake. I just remembered I also have another Asus in my parts closet at home, an AC3100. I’ll grab that and see whether I can set the two up side by side for investigation.
No, I was right, it's time to start over... further experimentation with the settings has resulted in further deterioration, to the point where some of my clients even started trying to resolve DNS inquiries on 127.0.0.1 and the Pi said it couldn't even contact itself on port 53. I appreciate everyone's trying to help, but it's quite clear now that a wipe is in order.