You said IPv6 was disabled.
So above DNS nameserver shouldnt't work anymore for local running processes/apps etc that need to resolve via DNS.
You can validate if its broken with below:
Which is most likely the cause of why nothing resolves anymore on the Pi-hole host.
Thats an OS thing and is unrelated to whats configured as upstream DNS servers in the Pi-hole webGUI (the screenshots).
Whats output for below ones to determine whats configuring networking for the Pi?
Oh another thing that comes to mind, you might profit from extending the TTL for local DNS records from default zero into two seconds by creating a new config file eg:
$ dig +noall +answer @localhost pi.hole
pi.hole. 0 IN A 127.0.0.1
$ dig +noall +answer @localhost pi.hole
pi.hole. 2 IN A 127.0.0.1
That stopped queries from my NAS flooding Pi-hole.
FYI:
$ man dnsmasq
[..]
-T, --local-ttl=<time>
When replying with information from /etc/hosts or con‐
figuration or the DHCP leases file dnsmasq by default
sets the time-to-live field to zero, meaning that the
requester should not itself cache the information.
This is the correct thing to do in almost all situa‐
tions. This option allows a time-to-live (in seconds)
to be given for these replies. This will reduce the
load on the server at the expense of clients using
stale data under some circumstances.
Thats sufficient for not having the router advertise IPv6 DNS server(s) to the clients.
Looks like NetworkManager (NM) is responsible for populating that /etc/resolv.conf file (via resolvconf).
Is the host manually configured with static IP details on the host itself or does it acquire those details via DHCP (maybe a static DHCP reservation)?
Could you post output for below one pls?
nmcli -t -f name con show --active | xargs -d '\n' -n 1 nmcli -p -f ipv4.method,ipv4.dns,ipv6.method,ipv6.dns connection show
You can edit above displayed NM "profile", if any, with below one (but first run above one!):
sudo nmtui
Above indicates you still have Pi-hole's "Enable IPv6 support (SLAAC + RA)" setting active while your intentions are to drop IPv6 support entirely!
Still have no clue why the version.bind query on the localhost IP doesnt return the version.
Could you also post output for below ones run on the Pi?
I do see at the moment when I hit enter after the command on my MacBookAir via VPN nslookup -class=chaos -type=txt version.bind 192.168.1.111 the following: Jan 7 07:54:52: gravity blocked version.bind is NODATA
and after the command nslookup pi.hole 192.168.1.111
Jan 7 07:55:46: query[A] pi.hole from 10.210.160.4
Jan 7 07:55:46: Pi-hole hostname pi.hole is 192.168.1.111
And from/on the Pi-Hole itself: nslookup pi.hole 192.168.1.111
Jan 7 07:57:55: query[A] pi.hole from 192.168.1.111
Jan 7 07:57:55: Pi-hole hostname pi.hole is 192.168.1.111
Jan 7 07:57:55: query[AAAA] pi.hole from 192.168.1.111
Jan 7 07:57:55: Pi-hole hostname pi.hole is NODATA
Glad the Pi resolves via DNS again.
You should see that nmtui configured DNS server(s) in below file now:
grep nameserver /etc/resolv.conf
I remember I experienced same where the IPv6 nameserver entry stuck when I enabled and disabled IPv6 on my router to try something out a month ago.
Some of my hosts still even now have that router advertised IPv6 DNS configured while IPv6 is disabled on my router:
If you want the processes and apps running on the Pi to use Pi-hole for DNS, you should configure its localhost IP 127.0.0.1 for DNS.
That IP resides on the virtual loopback interface named lo:
$ ip -br link show lo
lo UNKNOWN 00:00:00:00:00:00 <LOOPBACK,UP,LOWER_UP>
$ ip -br -4 address show lo
lo UNKNOWN 127.0.0.1/8
That lo interface is way faster as your physical eth0 interface, isn't depending on if a cable is connected or not and nothing gets broadcasted on the eth0 interface:
There is a drawback though if do so.
Whenever you break Pi-hole for some reason (upgrade/change/tweak), all processes on the Pi host loose DNS resolution.
Complicating diagnosing issues as even Pi-hole repair (pihole -r) or the debugger (pihole -d) wont be able to resolve via DNS.
Thats a new one for me.
On which list does that version.bind domain reside if query with below one?
pihole -q version.bind
I dont see any reason to block that one.
Or any of the other chaos domains:
pi@Pi-hole:~ $ pihole -q version.bind
Match found in https://raw.githubusercontent.com/DandelionSprout/adfilt/master/Alternate%20versions%20Anti-Malware%20List/AntiMalwareHosts.txt:
version.bind
pi@Pi-hole:~ $
Till now everything seems to work, and no errors. I'll will post after a week if I still have no errors.
