Hi all,
What's the best way to setup the pi-hole to reuse existing local DNS for local queries?
I updated /etc/dnsmasq.d/01-pihole.conf with the following:
It works but have some resolution problems.
Feedback is more than welcome! 
/DkY
I was also curious about this if someone has a complete solution. Was going to set this up at our office and the local DC would need to handle local DNS traffic for logins and such.
Easiest solution would be to use the automated installer and when you are prompted for the upstream, chose custom and input the IP addresses of the servers you would like to use as source.
In regards to integrations into a DC environment, we've had a number of users that have set up their systems in reverse. DC's DNS uses the Pi-hole as the upstream, so that all the AD records are resolved by the DC's and then any internet traffic is processed by the Pi-hole installation.
So when you say up-stream you mean the local DC is the primary DNS server and if the local DC doesn't have a DNS record for whatever the client is requesting the pi-hole is the next DNS server it checks? Then of course the pi-hole goes out to Google, OpenDNS, or whoever to resolve the client's request?
Not sure, but this should work like singularity explains.
Run the PIHOLE setup and enter only the local DNS (not the rest) server(s?) as upstream.
I assume your local servers have been installed correctly with the forwarders pointing to whaterver your forwarders are (Google, opendns, your isp, dnswatch, you name it)
In other words, your current dns is working without any issues.
Now. Take a test pc and manualy set ip to match ip range and local subnet (same as the pi) and gateway, like all your other machines., but change the dns to the address of the PI.
In theory this should work as the pi (hopefully) forwards all dns records needed for login to your upstream dns server.
If it works you can change dhcp to hand out the new dns server to the rest of the clients.
Before you do that, make pretty sure you have a stable pihole as your production is now depending on it.
Also use descent hardware if you have a lot of clients.
Perhaps create 2 boxes? Just in case.
If 1 box fails, all is needed is reboot a client and it will take dns number 2
Windows DNS client will not work if a dns server fails.
Even if you list 2 dns, still a reboot is needed for the windows client to switch to dns 2
Vise versa should also be possible.
Keep your local dns as source for the clients.
Build a pihole and choose opendns or google or..whatever during install and set the pihole as forwarder in your local dns server.
If you have a big site, it's probably best to create a test/pilot group.
There might be sites not working.
I would create new config file /etc/dnsmasq.d/00-localdns.conf and put line 'server=/internaldomain.tld/10.0.0.1' there. This way you can have all your clients pointing at pi-hole and thus get statistics right. Also this way pi-hole only forwards needed queries to your internal server. Also by using your own config file it won't get overwritten when you update your pi-hole.
Using this method messes up pi-hole statistics since all requests comes from internal DNS. If that doesn't matter then it's ok.
The "Official way" to do this would be as Dan suggested up there.
Run the installer and choose "Custom" at the DNS screen, then put in your local DNS server's IP.
I have it set up this way at work, cheeky raspberry pi hooked up behind my monitor sitting between me and the local DNS.
If you've already installed and don't want to go through the setup dialogs again, you can edit the values piholeDNS1 and piholeDNS2 in /etc/pihole/setupVars.conf and then run pihole -r to reconfigure (choose repair at this point)
Hi,
"both" methods should work.
Having raspberyy as upstream for local dns would have the least impact on a production environment.
I agree this makes stats kind of useless, but also consider the privacy rules that may exist in your company when using pihole as "internal/main" dns for your clients.
When you log all dns requests it might conflict with these privacy rules...
Yeah, very good point. In that case I would have it come after the company DNS.
I'm the only one that uses this one though, and it's probably technically a breach of IT policy to even have it but... meh
My reason for the ordering of the resolvers is that dnsmasq I don't think knows how to handle the MS proprietary record types and may slow things down while it decides if it should return NXDOMAIN or forward the request. If you PDC's get the requests first, then it's just like a standard AD install, with a custom upstream resolver instead of something like Google direct.