When Using Pihole, upstream AD DNS server is ignored

Within my configuration, I have pihole handed out to clients via DHCP, and pihole setup to query my AD DNS server, along with Google DNS.

Expected Behaviour:

When querying "vcenter.vm.localADDNSdomain.com" PiHole should attempt to query all upstream DNS servers, only two (both of my ADDS DCs) should respond with a potential answer.

Actual Behaviour:

PiHole reports NXDomain and can not resolve the address, 99% of the time. There is a rare occasion when PiHole does report the right information and things work properly.

Debug Token:

https://tricorder.pi-hole.net/zgetwxx64h

You've configured 4 upstream DNS servers. Pi-hole will always query only one of those. If this one does not know the domains, it will reply with NXDOMAIN

https://docs.pi-hole.net/ftldns/dns-resolver/#improve-detection-algorithm-for-determining-the-best-forward-destination

The DNS forward destination determination algorithm in FTL DNS's is modified to be much less restrictive than the original algorithm in dnsmasq . We keep using the fastest responding server now for 1000 queries or 10 minutes (whatever happens earlier) instead of 50 queries or 10 seconds (default values in dnsmasq ). We keep the exceptions, i.e., we try all possible forward destinations if SERVFAIL or REFUSED is received or if a timeout occurs. Overall, this change has proven to greatly reduce the number of actually performed queries in typical Pi-hole environments. It may even be understood as being preferential in terms of privacy (as we send queries much less often to all servers). This has been implemented in commit d1c163e.

Hmm,

That seems almost counter intuitive. If google replies with NXDomain then why is PiHole not trying the other servers?

In testing It seems I can mitigate the problem by just handing out my ADDS DCs IP as DNS server 1 to clients, but it seems like PiHole should be capable of trying all servers.

Because NXDOMAIN is a valid answer. The domain is not known to the server. How should Pi-Hole decide whether the domain does not exist at all or only the server doesn't know the domain?

If you want Pi-hole to query all servers, use the --all-servers option.

Why are you using Google as well as your AD? If you use AD only, can it forward to Google those queries it cannot resolve locally?

Is it only for a specify domain that you want AD to be the resolver? If so, dnsmasq can do this.

Please elaborate on your specifics.

Sure,

For most traffic on my home network, PiHole works fine, and I use Google as PiHole's upstream resolver. However, for the 3-4 devices that need to talk to AD to resolve my other sites (Laptop, Desktop, etc), they need to talk to AD.

As a result, when I setup DHCP, I configure PiHole as DNS server 1, so it's the first server available when a client makes a request. This configuration eliminated the old step I had where every device would query AD, and then it would forward requests it couldn't resolve to PiHole.

Since most devices don't need AD, this configuration is faster, and cleans up my logs within AD.

The problem is I have multiple AD domains. Eg. vm.localdomain.com, ad.localdomain.com, pbx.localdomain.com, etc etc.

The --all-servers flag should work just fine, as the extended resolution time for local addresses isn't a problem for me.

Try the server command in a new dnsmasq configuration file in /etc/dnsmasq.d

http://www.thekelleys.org.uk/dnsmasq/docs/dnsmasq-man.html

It works exactly as expected. I do agree with the guy in that thread though, a dedicated check box in advanced options or something would be welcome. Assistance is appreciated.

For all-servers? Mind that this may not do what users expect. If, for some reason, Google works be faster than your AD, the clients would still receive NXDOMAIN as this is a valid answer (as has been said before). I agree with @jfb that the server option may be a solution for you

server=/internal.thekelleys.org.uk/192.168.1.1 will send all queries for internal machines to that nameserver, everything else will go to the servers [configured in your Pi-hole]

I will need to investigate that, but at least for right now it bandaids the issue so I can work on other things.

I highly doubt that AD would ever be slower than google (It’s literally on the same box, so the VMware 10GB connection is the fastest possible interconnect), but this is already an edge case, so more edge cases are a valid point.

Any reason why you didn't consider enabling Conditional Fowarding for your AD DNS server via Pi-hole's Settings | DNS?
That's making use of aforementioned server option while avoiding manual changes to your configuration.

Because conditional forwarding does not support sub domains, and the WebUI only offers support for one forwarded domain.

Pi-hole's CF does support subdomains.
It does, however, accept only one target IP address (but wouldn't DCs replicate local DNS anyway)?

You may supply any domain for CF, e.g. vm.localdomain.com would be just as valid as localdomain.com.

Note that the latter would already match all subdomains as well.

Only if that wouldn't meet your requirements would you have to resort to custom dnsmasq configurations.

Indeed, for multiple target DNS server IPs, you'd have to provide a custom dnsmasq configuration for the second and further additional targets.
(Apologies for not grasping that earlier - I only picked up your mentioning to query a single AD DNS server in your original post, and wrongly chose to ignore your multiple DCs.)

Still, as mentioned before, using a custom server option seems the appropriate way to address your issue.

That is likely true for over 90% of your queries, but every now and then, individual queries may take longer.

Also note that in a default configuration, Pi-hole will periodically pick the fastest responding server as its preferred upstream.
You are meddling with this benefit by applying --all-servers (unless you'd be using just one public upstream DNS server).

You could also consider to use Pi-hole's CF as is, provided your ADs would either already replicate DNS among them, or you'd established an appropriate local DNS forwarding resolution chain for them.

This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.