You have two interfaces, eth0 (SLAVE) & eth1 (SLAVE), that are bonded resulting in a bond0 (MASTER) interface with an IP configured.
Plus a docker0 interface with IP implying that you're running Docker on the host.
Do you run Pi-hole in a Docker container or are you running it directly/bare metal on the host?
I’m running it in a Docker container on my Synology NAS. So does that mean I need to change the interface in my config file?
Well that docker0 IP 172.17.0.1 is outside your LAN's subnet which I suspect to be 10.1.1.0/24.
That would mean your clients wont be able to address/reach that IP for DNS.
I am not that familiar with Docker on Synology but try search here on Discourse!
In the end, below ones run on a client (Windows/MacOS/Linux) need to reply similar with the 10.0.0.2 IP being my own Pi-hole host:
C:\>nslookup pi.hole 10.0.0.2
Server: ph5a.home.dehakkelaar.nl
Address: 10.0.0.2
Name: pi.hole
Address: 10.0.0.2
C:\>nslookup pi-hole.net 10.0.0.2
Server: ph5a.home.dehakkelaar.nl
Address: 10.0.0.2
Non-authoritative answer:
Name: pi-hole.net
Address: 3.18.136.52
Only then can you proceed to configure your router DHCP service to advertise the Pi-hole IP for DNS to the clients (as the only DNS server).
I booted up a shell on my own Synology and it seems nslookup is available.
So you could also try do below one on the Syno to check at least if something is answering on that docker0 IP:
nslookup -class=chaos -type=txt version.bind 172.17.0.1
Or on that bond0 interface:
nslookup -class=chaos -type=txt version.bind 10.1.1.10
Answer should be similar like below:
dehakkelaar@nas:~$ nslookup -class=chaos -type=txt version.bind 10.0.0.4
Server: 10.0.0.4
Address: 10.0.0.4#53
version.bind text = "dnsmasq-pi-hole-2.87test8"
Looks like it is responding... but unclear how this helps.
I took a punt and changed my config to bond0, no surprise IPv4 is passing but IPv6 is failing.
You dont need IPv6 for your clients to resolve DNS.
Clients are able to query for IPv6 addresses via IPv4 and vice versa:
pi@ph5b:~ $ dig +short @127.0.0.1 google.com a
172.217.168.206
pi@ph5b:~ $ dig +short @127.0.0.1 google.com aaaa
2a00:1450:400e:80c::200e
pi@ph5b:~ $ dig +short @:: google.com a
172.217.168.206
pi@ph5b:~ $ dig +short @:: google.com aaaa
2a00:1450:400e:80c::200e
EDIT: Ow could you copy/paste the text output pls instead of screenshots?
Is easier to read and copy/paste from plus for people searching for similar issues.
With the mouse you can highlight/enclose the text code output with the </> button before posting here so the code gets formatted like above ^
Thanks I appreciate all the help, I'll try and format my responses going forward. 
However what are you suggesting at this point, to disable IPv6? Even with the settings changed to bond0 I'm still seeing the same behavior from my original post.
Below bit?
That is probably due to:
EDIT:
Leave it as it is if its working.
That debug message is only a sort of warning.
Yeah I'm still not having all my adds consistently blocked unless on the device I point DNS specifically at the Pihole.
While Chris' explanation sounds plausible, I don't understand why it's been working with that setup for as I said years. Then all the sudden it just stops working? Something must have changed somewhere. 
I dont know how you've configured Pi-hole in your network.
Did you configure the DNS IP in the router WAN/Internet settings or LAN DHCP service settings?
What does below one show (wait for 10 seconds timeout) ?
pihole-FTL dhcp-discover | grep 'Received\|dns-server'
You also have to consider that your router could push its own DNS server(s) to its clients via IPv6 router advertisement.
Do you have IPv6 enabled on your LAN and does your ISP support IPv6 upstream?
EDIT: Ow from that screenshot you posted in the OP it seems your configuring it in the WAN section.
What DNS server is configured now in that field?
Is it solely the Pi-hole IP or is there another like in the OP?
EDIT2: Ow sorry, it wasnt in the OP.
I mean this one:
@deHakkelaar Thanks for all the help, I'm a little fried tonight so will have a look a bit later.
You're right though lot of complexity; I have my UniFi Dream Machine that my Synology connects to, that runs Docker that's managed by Portainer that Pi-hole runs off of, so right there we've got 5 levels of potential problem causers. LOL!
One more for the road 
A large number of router manufacturers incorporate dnsmasq into their consumer routers and maybe even yours too.
And as Pi-hole has dnsmasq embedded into its code, have a read below how Pi-hole chooses when two (EDIT: or more) DNS servers are configured for upstream:
And there is a FAQ:
I wasn't aware you were running in Docker or using a bonded interface when I wrote that reply. Your initial post seemed like a common case where someone has a simple home network and the router turns out to be handling some queries, or using ipv6 to handle some queries, leading to some clients effectively bypassing the Pi-hole.
Regardless of the cause, if you're on the Mac and have multiple DNS servers configured in the OS, which you do, macOS's mDNSResponder service will send queries to all of them and go with the server which responds first. I suspect that means that Pi-hole and your router see most of it, and Google less so since it's external to your network. But even so, any queries hitting your router won't have blocking.
It may be that a recent OS or app update somewhere in the mix has subtly altered the timings, making your router a slightly quicker responder, leading you to see a big drop in Pi-hole blocking.
So I think actually just changing the IPv4 settings from eth0 to bond0 has done the trick. I had tunnel vision last night and was just testing with my MacBook and iPhone, however today when I checked a Windows machine and my iPad the blocking was working properly. I must just have cached settings on my iPhone and MacBook from all the tinkering.
However I do have one final problem I'm editing /etc/piphole/setupVars.conf to change the settings, but every time the container is restarted it reverts back to eth0. How do I get the config to keep the change to bond0?
I'm not that well versed in Docker but as Pi-hole is running in a container, I suspect that bond0 interface doesnt exist inside the container.
I suspect the container has its own interface inside the container which is most likely eth0.
And traffic gets port translated from inside to outside the container with below ones:
ports:
- "53:53/tcp"
- "53:53/udp"
- "67:67/udp" # Only required if you are using Pi-hole as your DHCP server
- "80:80/tcp"
Maybe someone with more Docker foo can help?
EDIT: Also:
For the record before this topic gets closed off I think this is a problem with iOS 16. After I changed the IPv4 settings on my Pi-hole everything appeared to be working. However my iPhone is the only device still is bypassing the Pi-hole. I compared to the other iPhones in my house and I'm the only one running iOS 16. I upgraded one of the other iPhones to iOS 16 and BOOM same issue.
Within the iPhone settings I've tried turning off the "Private Wi-Fi Address" and "Limit IP Address Tracking" options, but that did not work. I presume this is Apple trying to be overly clever, that if a DNS request gets sinkholed from the first server it tries one of the other DNS servers. Or perhaps it just broadcasts the request to all available DNS servers. If I change my iPhone DNS settings from dynamic to static and I point it at the Pi-hole all is well with the world and the blocking works as expected.
I know I could solve this across my network by making my Pi-hole the only DNS server on my router. However if for some reason the Pi-hole goes offline I'd lose all DNS.
SO it looks like for now I'll have to just statically set DNS on my devices running iOS 16 and I'll keep my ear to the ground for a better fix.
Could it be iCloud Private Relay - does this match up? "Private Relay protects users’ web browsing in Safari, DNS resolution queries, and insecure http app traffic"
Paragraphs 2 and 3 below explain how to turn it off per device or per network (for same user)
Per that dev doc are you seeing entries in your logs for their domains mask.icloud.com or mask-h2.icloud.com
Apologies for the slow reply. Reading the documentation it looks like iCloud Private Relay requires an iCloud+ subscription. I don't have a subscription, nor do any other members of my household. I checked my iPhone and there's not even an option to toggle it on/off so it's definitely not active.
I don't think iCloud Private Relay is the culprit in this case.
This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.