The issue I am facing:
I was attempting to add more subnets for Conditional Forwarding by creating a .conf file in /etc/dnsmasq.d (specifically, the 10.0.0.0/8 subnet) and my issue started. I removed the newly-created .conf file, restarted PiHole and even the Raspberry Pi when that didn't work, and the issue persists.
If my DNS server is the PiHole, DNS lookups timeout from a Windows command prompt and take a really long time from a PuTTy Terminal window to the RPi (over 10 seconds to look up). Details about my system:
I have been using Unbound on my RPi for a while for DNS, which the PiHole was configured to use (127.0.0.1#5335). I temporarily changed PiHole to use 9.9.9.9 for DNS and it remains unusably slow or flat out not working. What I have changed since installing Pi-hole:
See above. I also upgraded PiHole to the latest version I could get that's production version, no change in behavior observed.
I can't figure out if this is a problem with Unbound (doesn't seem likely since I changed PiHole to not use it) or Pihole configuration. Either way, I screwed it up and would really be grateful for some pointers!
Well I managed to correct the issue by either my full restore of my SD card from a recent backup and/or restarting my modem and router about a dozen time.
So I tried the provided tip for adding additional local networks for Conditional Forwarding, and the same thing happened all over again.
I am using a Synology Router 2600ac for the record; I wonder if it's part of the problem.
Anyway, the problem is my Rasbperry Pi won't resolve anything on interface eth0 IPv4. This appears to be the root of the problem. When I ran into this last weekend and eventually restored a backup plus restarted modem and router mutliple times, it magically started working. Now I'm in the same boat again. Cycling eth0 on the Pi isn't helping, and I don't know what else to try. I have generated a new debug log: https://tricorder.pi-hole.net/QUyrRYYU/
Thanks in advance for any assistance. This is perplexing!
You've applied several custom interface configurations:
*** [ DIAGNOSING ]: contents of /etc/dnsmasq.d
-rw-r--r-- 1 root root 151 Mar 18 10:29 /etc/dnsmasq.d/02-pivpn.conf
addn-hosts=/etc/pivpn/hosts.wireguard
interface=wg0
-rw-r--r-- 1 root root 16 Mar 19 11:35 /etc/dnsmasq.d/03-guest.conf
interface=wlan0
Those conflict with Pi-hole's Interface Listening behaviour, which is set to Allow only local requests.
As a result, your Pi-hole is not responding to requests on eth0.
You should remove all of those custom interface options and stick with Pi-hole's recommended setting of Allow only local requests.
If that wouldn't work with your VPN, switch to Permit all origins.
wg0 was added by the Wireguard install script, and the wlan0 was added months ago; this configuration has always worked up until the point I added (then removed) the changed in /etc/dnsmasq.d (I had created an 05-xxxx.conf file with lines to include 10.10.0.0/24 in Conditional Forwarding).
Nevertheless, I change PiHole config just now to permit all origins, and this resulted in no change in behavior.
Also, if I dig www.google.com @192.168.1.200, I get a timeout "no servers could be reached" error.
That was but the last step of my recommendation, and as mentioned, it would only be required if you would experience difficulties with your VPN.
The dig time-out would suggest that those custom interface options of yours are still active.
Please consider to remove those conflicting interface lines from your configuration files and switch Pi-hole back to Allow only local requests afterwards.
Sorry I didn't initially try removing the additional interfaces; I was in a time crunch but now have time to further troubleshoot. Upon removing the interfaces listed (by commenting out the appropriate lines in the *.conf files) and running pihole restartdns, it appears the problem is corrected as you suggested.
I then switched back to pihole -a -i local to "Allow only local requests," and we're still working correctly.
Next step, one at a time I added back the additional interfaces by removing the # comment tag from the conf files, then restarted with pihole restartdns. On each one of the two, the problem returned.
So I have the additional interfaces disabled for now. I also switched back to my local DNS via Unbound (127.0.0.1#5335) and it's still working.
I am at a loss as to why this worked before my Conditional Forwarding changes, but now it does not work (and Conditional Forwarding has been disabled throughout my troubleshooting, by the way). Any ideas? My desire is to have PiHole working for my wired and wireless LAN, and hopefully (but less important) my Wireguard/PiVPN setup. Like I said, it was fine before I started poking around Conditional Forwarding. Trying to learn here, not blame, and I really appreciate the help!!!
EDIT: I later uncommented out the *.conf files above and ran pihole -a interface all then pihole restartdns. Pihole is listening on all interfaces as expected, dig command takes a second but resolves correctly. I then ran pihole -a -i local again and pihole restartdns, and everything still works (still listening and responding to wlan0 interface in addition to eth0, for example.
That would be expected, as those interface options are exactly what causes your issue.
There would also be no need for defining them, as Pi-hole's Allow only local requests setting is designed to handle all subnets that its host machine has interfaces for.
Usually, that is sufficient to correctly handle DNS requests, regardless of the interface they arrive on. This should also cover the wg0 interface of your Wireguard server colocated on the same machine as Pi-hole. Switch to Permit all origins only if your Wireguard VPN clients wouldn't be able to resolve DNS.
For assisting you with Conditional Forwarding, a debug token with your respective configuration attempt would be helpful.
When I remove the extra interfaces from the *.conf files, I get no DNS resolution on the Wireguard network until I use the "Permit all Origins" option based on my testing right now. Your post tells me it is better to not have the additional interfaces, and use the Permit all Origins instead if necessary (as it seems to be in my case). I still need to see what the guest/wlan0 network does, but this is progress.
I will see how the attempts at changing the Conditional Forwarding pan out now with this setup in place.
Yes, as any manual interface option configuration will conflict with Pi-hole's UI controllable Interface settings. Switching modes cannot produce the advertised outcome anymore, as Pi-hole shouldn't and wouldn't touch your custom configuration files.
If you'd prefer manual configuration over UI control, by all means go for it, but in that case, you should consider to make yourself thoroughly familiar with dnsmasq's related configuration options and be willing to resolve any conflicts on your own.
You'd also have to accept that Pi-hole's UI would no longer reflect your actual situation and you should refrain from using it, and probably you'd have to remember to recheck your configuration for potential conflicts after upgrading Pi-hole to a new release.
No, getting into the specifics of DNSMASQ is likely not going to end well for me. And I'm happy to use the intended mechanisms to configure PiHole without "hacking" an unsupported function.
After a good 15 hours under the current setup, I have found (to the good):
Eliminating the extra interfaces wg0 and wlan0 from PiHole's config files allowed me to finally get Conditional Forwarding working for 10.10.0.0/24 (it's also possible I was initially pointing to the PiHole address instead of the 10.10.0.0/24 Gateway Address in my earlier attempts, I'm not sure)
Running pihole -a -i local keeps pihole listening on the expected networks in addition to my Wireguard network (10.6.0.0/24).
Now my last remaining challenge is to get Conditional Forwarding for my IPv6 addresses, if possible. The line I added to my .conf file reads rev-server=fe::/64,192.168.1.1. I made this change about 12 hours ago and I'm still getting the IPv6 address instead of the hostname in the Query log. On the chance someone can point to my mistake, I generated a debug log at https://tricorder.pi-hole.net/fMzigHuN/ .
The forwards are in 05-forwards.conf, for what it's worth.
Not sure I'm seeing what you're referring to, but to my understanding:
10.10.0.1 is on "private"
192.168.1.1 in on "home.arpa"
These are both gateway addresses to my physical router (192.x.x.x is the LAN and 10.10.x.x is my Guest Wifi).
I see what you're saying about "same domain name" now. My router doesn't give me the option of giving the Guest Wifi (10.10.0.1) a name like it does my regular LAN.
Your debug log suggests that private isn't used as a local domain name.
Instead, home.arpa is reported by both DHCP servers.
(I've edited my previous post to include the corresponding excerpts.)
If your router is handling both address ranges, it may be possible that the existing server=/home.arpa/192.168.1.1
is already enough to handle local domain lookups.
If your router is managing your guest network strictly separate from your home network, an additional entry with 10.10.0.1 as a target may yet be required.
For reversing IPv6 LLAs, you could use a line like the following:
rev-server=fe80::/64,10.10.0.1
There is no guarantee that IPv6 reverse lookups will work under all circumstances, though.
It would depend on your router's capabilities to correctly associate an IPv6 address to a device. Particulary, if your devices would employ certain procedures as IPv6 Privacy Extensions, your router may fail to do so.
If your router is handling both address ranges, it may be possible that the existing
server=/home.arpa/192.168.1.1
is already enough to handle local domain lookups.
Before I added the rev-server=10.10.0.0/24,10.10.0.1 server=/private/10.10.0.1 lines, I was getting no name resolution for devices in this network in my PiHole query logs. After adding the above, name resolution started showing up in the query logs. I don't know of the server= line made a difference or not; I made both changes at the same time. In any case, I am getting proper name resolution on that network at this time (since yesterday).
I will try pointing the rev-server=fe80:: item to 10.10.0.1 and see if it makes a difference, as you suggest, and report back.
EDIT: Is there a command I can issue to see what hostnames have been gathered by conditional forwarding (I'm connected to my Pi via remote SSH)?
For most cases, that should produce both the forward as well as the reply.
On busy networks, or if 10.10.0.1 took a long time to answer, you may have to adjust the number of lines to include after the match, e.g. -A3.
Alternatively, just use pihole -t to see queries as they happen, or use Tools | Tail pihole.log for the same purpose.
EDIT:
And of course, if you would be interested in the result of a specific reverse lookup, you may just send a respective nslookup or dig to your router, e.g.
So I don't know if it makes a difference, but I can assign a domain name to my Guest network. So I named it "private" to match what the Conditional Forwarding for that network was expecting in PiHole.
I'm still not getting name resolution on my IPv6 range, though. I have the gateway address set to 192.168.1.1, though, as that made more sense to me. Is that a problem? The grep I modified to "reply fe80" and the only hits I get say NXDOMAIN so nothing showing yet. May not be possible to get what I seek.
Directing an nslookup for a known hostname at your router should return all IPv4 and IPv6 addresses your router knows to be associated with that name.
If it doesn't return any IPv6 addresses, you could consider to create the respective Local DNS Records for your IPv4 and IPv6 addresses via Pi-hole's UI, or edit /etc/pihole/custom.list for the same effect.
That looks like a good workaround for what I'm seeking. Thanks, @Bucking_Horn! Top-notch help and explanations here! I feel like I understand so much more of how this fits together now, and I really appreciate it.
