TL / DR: leaked mDNS requests were mixed out on the Internet as requested by several homekit-related entities. After enabling the optional dnsmasq DHCP server on my USG router with the "Enable Hostfile Update" option as well, the USG DNS server now serves the * * local DNS request that used to fail. I think this helps the homekit system work better, though I don't know why it's not solely reliant on mDNS / Bonjour.

I've had my ups and downs with HomeKit, but recently I stumbled upon something that will no doubt make HomeKit, and hopefully my home network better (still not the silver bullet).

Because of this complex nature, it is a cross post with r / Ubiquity and r / pihole. I guess some of this information is just generally useful for anyone working with any of these three services.

I've had mediocre success with some previous iterations of Netgear Nighthawk routers and a Netgear Orbi. Finally, I switched to Unifi and that's good, but there are some subtle settings that really make a huge difference (most of them are unrelated to this post).

My current network is configured like this:

* Unifi USG-3P router acts as DHCP server
* Raspberry Pi 4 as Pi-Hole DNS server with unbound as upstream DNS resolver
* Raspberry Pi Zero W as a redundant Pi-Hole server with unbound upstream DNS resolver

When I initially set up DNS on USG, I set up both WAN DNS and DHCP DNS to point to my two Pi-Hole servers. This worked well, except when I turned on "Use Conditional Forwarding", I would get a cough in a loop where the pihole would send .local requests to USG, and it would again provide a DNS request to the pi hole until they both went for 100% cpu and then the FTL pihole service would die. This really confused me for a long time, but now it makes sense. USG used the old style DHCP server (dhcpd I think) and would not keep a hostfile list of all dns clients. When switched to dnsmasq, it keeps track of dhcp host names and serves them by DNS requests.

Before setting up this dnsmasq dhcp setting, I had noticed that the pi hole received a lot of requests from all my home kit related devices, and also a ton from my windows computer (disconnected from work domain) to .local addresses. These were just being passed on to the internet, which is not ideal for privacy reasons, and just general, it does not work, so why try. Because of all this leaked mDNS equipment, I blocked .local requests in pi-hole. This created problems! pihole defaults to respond to blocked domains by returning (0.0.0.0) (https://0.0.0.0). Using the app called "Discovery" in the iOS app store ((https://apps.apple.com/us/app/discovery-dns-sd-browser/id305441017)(https://apps.apple.com/us / app / discovery-dns-sd-browser / id305441017)) I found that all my homekit devices had a real ip address on each device and each had a different ip address (0.0. 0.0) (https://0.0.0.0)! I think this caused a lot of unnecessary problems in the homekit. After changing the default response from the pihol to NXDOMAIN, the (0.0.0.0) (https://0.0.0.0) ip address listed in the "Discovery" app also went missing.

This leaky mDNS thing (that's how it is described when doing a "digging" at a .local address in a unix-derived OS) has bugged me for a long time since I noticed it in pi-hole logs. FYI, using tools like ping .local is not a good way to verify that your router is properly serving local host names, and will then work with the pihole option for "Use Conditional Forwarding". To test your router's ability, you can use "nslookup" with windows and "dig" with unix. This will force it to use DNS rather than mDNS to resolve the name.

Finally, I wish there is a way for all this to work while still using my piholes for the WAN side of my USG. Any .local address that is not resolved by USG will just get coughed in an infinite loop with the pihole until the FTL server crashes. The way it is set now, any undetected .local address is sent to Cloudflare. (Names still unresolved include "wpad.local" "wpad..local "".local ""..local "and several other annoying variants that are being spewed by my Windows PC.) I understand that there may be a .json configuration file that I could do on USG, but I'm not prepared to go there yet.