[aconfer]

At least on macOS I found that if:

DNS Server 1 = Pi-Hole

DNS Server 2 = ISP DNS Service, OpenDNS, your router whatever

when pi-hole blocks the ad's DNS query, macOS will treat that as a DNS failure and use DNS Server 2 as a fallback. Resulting in the ad being shown.

Doing (A) was my first attempt and at least using a Ubiquiti router, if Pi-hole blocked a DNS query it would always fallback to the secondary DNS server. In my environment, the only way I was able to get pi-hole to work consistently was to set the pi-hole server as the only DNS server in the DHCP server.

[Narkov]

> when pi-hole blocks the ad's DNS query, macOS will treat that as a DNS failure and use DNS Server 2 as a fallback. Resulting in the ad being shown.

My experience with OSX and Pi-Hole doesn't match your experience. There's a difference between appearing to be in a failure mode (i.e. timing out) and returning blocked (null/0.0.0.0) results.

[aconfer]

I set this up a few years ago and now that time has passed I'm not confident enough to claim what exactly led me to that conclusion. I never got around to setting up a second pi-hole server which is what led me to click on the article above. 3 years in and I've never had a blip in service so I just haven't prioritized it.

I did go and test this now, and agree with you. On macOS I set my primary DNS to pi-hole and secondary to 8.8.8.8. running dig on api.segment.io (blocked on pi-hole by default), it resolved to 0.0.0.0 via pi-hole and did not try 8.8.8.8 on any attempt. So my earlier comment is incorrect above and setting a secondary DNS server as a back-up may work.