Lol. Will do!
I'm hoping there's an elegant way to resolve this in a way that allows for the Pi-hole to show the device making the request. A lot of options I'm seeing are looking like all queries will look like they're coming from the USG.
@Bucking_Horn, so the people over at Ubiquiti are saying it could be an issue with Pi-hole if I'm able to set a public DNS and I stop getting the DNS Timeouts; which I was afraid of...two different products pointing at each other and saying it's the other's fault.
Oh come on, I am not into blame games 
I did say it was a network configuration issue, rather than Pi-hole - never blamed USG nor Pi-hole.
My feeble solutions offered one approach involving USG and another involving Pi-hole.
I am afraid my option 1 will not allow for this, as masquerading will make your requests to appear as originating from your USG (I think I already did mention that in my answer, though).
I have been thinking about this, and maybe there is a third option.
What is the IP address range of your VLAN subnet (192.168.3.0/24) ?
Can you ping a VLAN client machine from your Pi-hole, preferably one that allows you to open a command prompt and that you know to answer to ping requests:
ping -c 3 192.168.3.x
Replace x with the appropriate number.
I have a similar setup with a couple of exceptions. I'm using the Edge Router X and I haven't setup unbound yet. That is what brought me to this thread.
For my setup I have a destination NAT rules set for both VLANs to force traffic to my Pi-Hole.
I can ping from my Pi-Hole into any of my subnets. To do this I have a firewall (IOT_IN) rule to drop all traffic to my Trusted Networks list, but you can set that to single subnet. I use a list so I cover multiples networks.
From time to time I do still get the 0% experience but I ignore it as there doesn't seem to be a noticeable performance hit.
Thanks to Bucking_Horn for the PM
Hahah, I know you didn't! But, it just always seems to end up that way. I do appreciate your help in this, though!
The IP ranges are as follows:
LAN: 192.168.1.0/24
ADC: 192.168.2.0/24
IoT: 192.168.3.0/24
The bottom two are the VLANs.
And yes. I can ping my Roku (192.168.3.6) from my Pi-hole (192.168.1.188).
Can you clarify this? Its my understanding that all wold need to be on a VLAN. At least that is how I have mine setup.
The top listed address is the default LAN network created by Unifi when you initially set up your network. The next two addresses are the VLANs I created to house my IoT devices and Security cameras.
Hey @Grady, would you be able to reproduce @Staudie's settings from above with your USG?
After a quick perusal of his post, I'd say he managed to produce a configuration that conforms with my option 1, without the hassle of figuring out how we could do this via CLI.
Good.
That means you have a working route from your .1.0 to your .3.0 subnet.
We have established that your USG is able to connect your subnetworks from a technical point of view, and also that it indeed does offer full connection support as fas as ping packets go (which use quite a different protocol than DNS).
Now let's verify this applies to your DNS traffic as well.
We need tcpdump on your RPi machine running Pi-hole for this (click for details)
If tcpdump isn't already installed, do so by executing the following commands from an RPi terminal:
sudo apt-get update
sudo apt-get install tcpdump
From an RPi terminal, execute the following:
sudo tcpdump -c 3 -n src net 192.168.3 and udp port 53
Then, from a terminal on a VLAN client in your 192.168.3.0/24 subnet, issue the following:
nslookup pi.hole
Once issued, you should see some lines appearing on your RPi.
tcpdump will finish executing as soon as having received 3 packets (as per -c 3).
As your RPi will likely not answer these DNS requests yet, you might have to repeat the lookup from a VLAN client.
Alternatively, you can always press <CTRL> <C> to cancel execution of tcpdump.
If you do, we will have established that DNS packets are reaching your RPi (but not Pi-hole itself yet). When you confirm this as working, we can try to fix the latter next.
Here is a link to the post on UNBT that I used to setup my Pi-Hole.
[Step-By-Step Tutorial/Guide] Raspberry Pi with UniFi Controller and Pi-hole from scratch (headless)
Forgot to mention for my Chromecast I had to open mDNS port 5335 in IOT_IN. Otherwise I couldn't see it from my main LAN (just a thought).
Well, @Staudie is using an EdgeRouter. I don't have an EdgeRouter but it offers some deeper CLI config possibilities that the USG does not. I've read/seen a lot of articles about how EdgeRouters easily achieve what I'm trying to do but it hasn't been 1:1 replication in the USG.
I'll try your second suggestion here in a bit!
Apologies for the lack of updates: Here's a new-ish development. I got a Cloudkey Gen2 Plus because I kept seeing Unifi posts about custom configs with it. I also got tired of my Controller being on my PC. I haven't made any custom configs just yet but, the "DNS Timeouts" have definitely lessened. They still happen, but instead of several times a minute, it's maybe 1-2 times every few minutes.
Not sure why or how or what changed, but...it's a new thing. I'm going to tackle this more tonight, hopefully and will keep you guys posted!
EDIT: Oh, another thing I did - I gave every device a static IP in the Unifi Controller and just created entries for all of them in my Pihole's /etc/hosts file. This works as a very manual way of getting the Pihole to resolve every hostname on the network.
For my setup I'm running the Unfi controller on the same PI as my Pi-hole, with a static IP assigned by my edge router. Your timesouts are more in line with mine now. I going to try adding the static IP to the host file to see if that helps.
*slight sigh*
As you've added a new piece of network equipment, that'll quite likely have rendered our previous analysis efforts obsolete or invalid. 
*hopeful look*
Though I wouldn't generally recommend throwing extra pieces of equipment at problems that haven't been fully understood:
As you obviously already are observing improvements for your problems, that might as well have been the right step to take.
FWIW. I recently incorporated a Pi-hole into my Ubiquiti UniFi network and came across the same issue as you did with my VLAN clients not being able to use the Pi-hole successfully. I have VLANs for IoT, Games, & Media.
My "solution" was to create LAN-IN FW rules for each VLAN that allowed it to send DNS requests, via port 53, to VLAN1 where my Pi-hole resides. Everything works perfectly and I don't get any DNS errors reported with my USG 3P from the Controller that resides on a Cloud Key. Each VLAN has a total of three FW rules as you can see from the first image for the Games VLAN.
Hey, thanks for adding your setup! Yeah, in my initial post I added screenshots of my firewall rules. The only difference I think, is that I don't have firewall rules specifying the Pi-hole TO the VLANs. I just have it going VLANs to Pi-hole.
Just to make sure I didn't confuse you on what I did, I actually created three separate FW rules for each VLAN.
-
The first one allows all traffic from my untagged VLAN1 to the VLAN-Games. (Not sure that this one was required as I understand that the untagged VLAN1 traffic is not blocked to any tagged VLANs, by default.)
-
The second one allows only DNS (UDP & TCP, port 53) traffic from VLAN-Games to VLAN1. This is the primary rule for my game consoles on VLAN-Games to send DNS requests to the Pi-hole on VLAN1.
-
The third rule blocks all other traffic from VLAN-Games from getting access to VLAN1.
Yeah, I followed you. Here are the firewall rules I have setup:
The top two allow my Private LAN to talk to the two VLANs.
The next two allow my VLANs to talk to the Pi-hole. I have an address/port group set up for the Pi-hole address and Port 53, so the VLANs (IoT and ADC) are being allowed to talk to the Pi-hole address (192.168.1.188) and the Port (53).
I also have rules dropping traffic FROM the VLANs back to the Private LAN, so, I think our rules are very similar, if not the same, maybe except that second rule you have. I'm looking at reproducing that rule but it looks similar to the ones I already have. Is 192.168.1.165 your Pi-hole address?
Yes, .165 is my Pi-hole. I'm using the "new" interface on the Controller Settings so things may look a bit odd.
Here's the same images with the "original" interface
Yeah, I'm nearly certain our firewall rules are the same.