The debug log you uploaded in your original post shows conditional forwarding disabled:
CONDITIONAL_FORWARDING=false
In the original debug log yes.. I turned it on since..
After some more research in LAN logs.. it looks like ALL those Apple cache and Bonjour DNS lookup addresses were initiated by our lone iMac... I have validated that content sharing is OFF on that machine, so it's not clear what initiated those lookups.
Anyway, I placed the REGEX from @Bucking_Horn into the pi-hole blacklist and also added the Bonjour names to the list.
I'll check in the am as to impact.
Ok.. so 24 hrs later having blacklisted the errant Apple content caching and Bonjour service ..
Looks like things are running as expected - altho' I don't ever recall adding them previously.
Temp storage is running at 10%
pi@raspberrypi:~ $ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/root 28G 6.2G 20G 24% /
devtmpfs 459M 0 459M 0% /dev
**tmpfs 464M 43M 421M 10% /dev/shm**
tmpfs 464M 6.3M 457M 2% /run
tmpfs 5.0M 4.0K 5.0M 1% /run/lock
tmpfs 464M 0 464M 0% /sys/fs/cgroup
/dev/mmcblk0p6 68M 23M 46M 33% /boot
tmpfs 93M 0 93M 0% /run/user/1000
/dev/mmcblk0p5 30M 462K 28M 2% /media/pi/SETTINGS
tmpfs 93M 0 93M 0% /run/user/999
and LOG sizes look OK
pi@raspberrypi:~ $ ls -la /dev/shm
total 43924
drwxrwxrwt 2 root root 220 Dec 3 21:20 .
drwxr-xr-x 15 root root 3660 Dec 3 18:13 ..
-rw------- 1 pihole pihole 323584 Dec 3 21:20 FTL-clients
-rw------- 1 pihole pihole 108 Dec 3 21:21 FTL-counters
-rw------- 1 pihole pihole 65536 Dec 4 16:25 FTL-domains
-rw------- 1 pihole pihole 12288 Dec 3 21:20 FTL-forwarded
-rw------- 1 pihole pihole 28 Dec 4 18:00 FTL-lock
-rw------- 1 pihole pihole 53248 Dec 3 21:20 FTL-overTime
-rw------- 1 pihole pihole 44826624 Dec 4 18:00 FTL-queries
-rw------- 1 pihole pihole 12 Dec 3 21:20 FTL-settings
-rw------- 1 pihole pihole 69632 Dec 4 17:25 FTL-strings
and 24-hr blocking stats look about normal.
THANKS to everyone for their input... MUCH APPRECIATED!!
Glad it's working 
Just want to point out this is a workaround rather than a cure - we now have effectively crippled content cache discovery on your network now.
Also note: Pi-hole or your Apples are not the culprit - your USG is misbehaving.
Content cache discovery and Bonjour are active by default on Apple devices, and it is normal they appear on a network where Apple devices are present - but only a few probes per device a day.
The reason they occured by the million is that your setup included a loop for DNS SRV requests.
The fault was caused by your USG not answering that request with NXDOMAIN, probably because it doesn't recognize the associated host as being of local origin.
Since you've said you didn't touch your USG's WAN DNS settings, it seems likely an update for your Unifi USG is the possible source. And indeed, I have found at least another user with your problem in the Unifi forums. Either that, or you only recently created the loop by enabling Conditional Forwarding in Pi-hole.. disabling it again would help avoiding the loop, but also deprive you of individual device information in Pi-hole's Query Log.
In the current configuration, valid content cache discovery requests or Bonjour network neighbourhood discovery requests are not handled correctly in your network. If you choose to leave it as it is, you should be aware that some services on Apple devices may not be working as expected, e.g. wireless printing over AirPrint is likely to fail without Bonjour.
To fix this, you have to somehow convince your router to supply a correct answer, either by a firmware update patched accordingly, or by injecting the appropriate DNS record into your USG.
As this is not a Pi-hole matter, you'd have more luck on searching Unifi's forums on this, and maybe Apple's for information on their DNS behaviour specifics.
In the meantime, enjoy your Pi-hole filtering again 
This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.