There was a version of Awair devices that used 8.8.8.8 for DNS, no matter my pihole.

At the router level, I then forced all 8.8.8.8 traffic to be transformed into traffic to my pihole.

You can do the next step, but you need a router that supports it and the patience to handle it.

You shouldn’t need to do this.

I force all outgoing traffic to 53 not Pi-Hole IPs (I run redundant) to go to a Pi-Hole instead. Initially I did tgat for Chromecast. However, I doubt Chromecast still cares. Why do you think Google push Do{H,T}?

Chromecast devices (some? all?) have Google's public DNS servers hard coded. Paul Vixie wrote a nice rant about catching these devices trying to bypass his local DNS servers.

All Chrome based browsers have 8.8.8.8 8.8.4.4 hardcoded under the guise of "helping resolve navigation errors", except its not helping anyone but Google in gathering statistics. Domains like hls.ttvnw.net (no A record) receive perfectly valid DNS reply (NOERROR, response code 0, DNS Query completed successfully) but trigger this feature and call hardcoded Google DNS resolver. Even domains that dont exist at all and browser receives valid response (NXDOMAIN, response code 3, Domain name does not exist) trigger to snitch on the user to hardcoded Google DNS resolver. No errors, google called.

More likely the destination IP address is hard coded, so no name resolution is ever required.

Well, it is also possible to not use port 53 as UDP to resolve DNS.

So, if it is using HTTPS for DNS resolution, I don’t know how you would block that.

If you could install a self-signed cert onto the device, you could MitM the HTTPS traffic and see what it is doing.

> if it is using HTTPS for DNS resolution, I don’t know how you would block that

By filtering traffic sent from that particular device based on a query to your DNS filter to approve or deny the destination address. (Some implementation work probably required.)