I have noticed that something didn't quite seem right with my network, and Pi-Hole.
I generally leave it to just do its thing, and only pay attention when upgrades are needed.
Bit of digging about, and I started to notice certain sites were not being blocked, despite definitely being on a block list.
Looking at my stats and data, I have started seeing many, many AAAA requests, despite IPV6 being disabled (or at least as far as I know) on my network (ISP is Sky UK, using their Q-Hub)
The queries come from multiple types of devices - Android phone, iPhone, TVs, Rpis, but not all devices on my network.
Looked through my router settings, and IPV6 is disabled.
However, i did stumble on some settings that i have not seen before, so assume they are new following an update (no notification to users)
Any ideas if these could be interfering somehow? I have no idea what they are:
Disabling IPv6 won't stop client software from requesting type AAAA records. e.g. nslookup would commonly send both type A and AAAA queries for a given domain.
It's also not unexpected to see a client use its link-local IPv6 address (range fe80::/10), even if the router wouldn't advertise a public IPv6 prefix (range 2000::/3) because it has no public IPv6 connectivity.
Which of the queries shown in your query log should have been blocked?
Per the linked documentation:
No DHCP context has been configured for this interface. Check your DHCP settings.
This warning is expected during debug log generation as Pi-hole is trying to request a DHCP lease on all available interfaces. We do this to test that the server replies properly.
When an interface does not have a DHCP configuration (such as the loopback interface lo , or other special interfaces such as docker0 ), this warning is printed. You can safely ignore it when it happens only during DHCP testing, e.g., during Pi-hole debug log generation. If it happens often, you can use the option no-dhcp-interface=IF_NAME (insert the interface name here) to specifically disable DHCP on this interface.
Well, I have partially solved this...
Turns out OnePlus force Google DNS at an OS level.
I managed to circumnavigate this by having my pihole advertise itself twice as a DNS server.
I created a dnsmasq.d conf file with the following:
This works well.
I'm still perplexed by AAAA queries being answered though