I do experience similar behavior. The DNS requests are received by the pi-hole server, get resolved, but they will not be forwarded to the originating client, thus breaking name resolution. DNS works on the pi-hole with every public server that i tried.
Thanks. nslookup succeeded. I did it on my local client and it also worked. I tried it from my client both using and not using the pihole for DNS. To be clear, it worked in all cases.
pi@homebridge : ~ $ nslookup duckduckgo.com 1.1.1.1 Server: 1.1.1.1 Address: 1.1.1.1#53 Non-authoritative answer: Name: duckduckgo.com Address: 52.149.246.39
That would preclude your router is blocking outbound DNS traffic.
From a client that uses Pi-hole for DNS (not from your Pi-hole machine), what's the output of
nslookup pi.hole
nslookup flurry.com
nslookup flurry.com 80.241.218.68
What's the exact URL you are using to access Pi-hole's admin UI when using your router for DNS?
Thank you.
Using my macbook air, I set the DNS to the IP address of the Pi. I ran the following from the macbook terminal:
backdoc@MacBook-Air ~ % nslookup pi.hole
Server: 10.0.0.50
Address: 10.0.0.50#53
Name: pi.hole
Address: 10.0.0.50
backdoc@MacBook-Air ~ % nslookup flurry.com
Server: 10.0.0.50
Address: 10.0.0.50#53
Name: flurry.com
Address: 0.0.0.0
backdoc@MacBook-Air ~ % nslookup flurry.com 80.241.218.68
Server: 80.241.218.68
Address: 80.241.218.68#53
Name: flurry.com
Address: 0.0.0.0
I am using http://10.0.0.50/admin/index.php from my macbook to access my pi, which works whether or not my macbook's DNS is using my pi-hole or my router's address.
Just in case I'm doing something wrong on the client, here are my client settings:
FWIW, my macbook network configuration looks like this:
And, the DNS alternates between 10.0.0.1 or 10.0.0.50, depending upon whether or not I'm trying to use the pihole for DNS, which in order to reply to the post, I have to be using the router's address atm:
All of your nslookups have returned ok so far:
You can resolve a public domain (duckduckgo.com) through a public DNS server (1.1.1.1), pi.hole can be resolved, Pi-hole does block domains as expected (returning 0.0.0.0 for flurry.com), and so does a public blocking DNS server.
What does nslookup duckduckgo.com pi.hole return?
And how did you configure your router to make use of Pi-hole?
I'm confused what "pi.hole" is and how it works. I'm familiar with /etc/hosts and thought it might have been configured there (on the pi-hole), but it wasn't. Consequently, I wasn't sure the context you needed me to run, "nslookup duckduckgo.com pi.hole", so I ran it all 3 ways that I could think of:
- From the pi-hole
pi@homebridge:~ $ nslookup duckduckgo.com pi.hole
nslookup: couldn't get address for 'pi.hole': not found
- From the client using router's DNS
backdoc@MacBook-Air Downloads % nslookup duckduckgo.com pi.hole
nslookup: couldn't get address for 'pi.hole': not found
- From the client configured to use pi-hole for DNS
backdoc@MacBook-Air Downloads % nslookup duckduckgo.com pi.hole
;; connection timed out; no servers could be reached
I go to the router's internet page and instead of using the ISP's DNS, I hard code the pi-hole's IP address. I did that back when my pi-hole was on wifi and it worked fine. But, since I reconfigured it to use ethernet, if I configure the router to use DNS, I can't get out to the Internet at all, even from the router itself. So, of course, no clients can reach out.
This domain is defined in /etc/pihole/local.list. In my case, the file contains the following. Your IP's will be different and your unique name on line one will be different, but pi.hole will always appear on line 2.
cat /etc/pihole/local.list
192.168.0.160 nanopi
192.168.0.160 pi.hole
Only the Pi-hole can resolve this name to an IP, which is why we use that as a test in our troubleshooting steps.
The unique name is also used to access the web admin page: http://pi.hole/admin
Thanks for the explanation. After sending my reply, I found that file and the custom list, too (which was empty).
I’m away from my house now. But, I think it also had my homebridge hostname.
It looks like /etc/hosts and kinda made sense after finding that file.
I appreciate you helping me troubleshoot. Are there any other files that might have gotten my old IP stuck in it? I’ve already used “find” and “grep” to search. If it’s not a config file somewhere, I don’t know what else to try.
Manual changes shouldn't be required if you switch from wlan0 to eth0.
Did you run pihole -r with Reconfigure to that effect?
Yes. I did. I think there are two options and I ended up trying repair and reconfigure. Ultimately, I ran pihole -up. And, this evening I noticed that it required updating, so I just ran it again. And, then I tried changing my DNS on my client and still have trouble.
I know it would probably be easier to just wipe it and start over. But, I've never been one to go around problems. I like to plow through them because I feel like I learn from them. Maybe this effort will benefit the project in some way, if no other way than future users encountering the same problem. So, I'm good with troubleshooting this, at least for now. It bugs me not knowing why it's messed up.
You may have accumulated a lot of (potentially conflicting) settings in your network interface configuration during your multiple reconfiguration attempts.
Let's have a look at those settings. What is the output of the following command on your Pi-hole machine:
grep -v '^#\|^$' /etc/dhcpcd.conf
I did hand edit it. I had never heard of dhcpCd.conf. I remember it being dhcpd.conf. So, that confused me and I accidentally had it named wrong. But, I thought that I had it named wrong when it was actually working. But, just to be clear, I currently have it named dhcpcd.conf (as seen below).
pi@homebridge:~ $ grep -v '^#\|^$' /etc/dhcpcd.conf
hostname
clientid
persistent
option rapid_commit
option domain_name_servers, domain_name, domain_search, host_name
option classless_static_routes
option interface_mtu
require dhcp_server_identifier
slaac private
#### static ip_address=10.0.0.135/24
#### static routers=10.0.0.1
#### static domain_name_servers=208.67.222.222 208.67.220.220
interface eth0
static ip_address=10.0.0.50/24
static routers=10.0.0.1
static domain_name_servers=127.0.0.1
I want to thank you for your efforts. You have been the only one who has been able to offer some troubleshooting steps. So, I’m very appreciative. But, since nobody else seems to have any suggestions, once you are out of ideas, I may just have to reinstall on another pi or some other box. Are you ready to call it unsolved and move on? I’m good with continuing to dig into it. I’d rather figure it out. I’m just not good enough with networking to know what to try next.
Sorry for the delay - your answer managed to escape my attention.
Your dhcpcp.conf looks ok, there's only one active static configuration for eth0. Since you seem to have renamed that file sometime in the past, that may or may not have contributed to your issue, though that's purely speculative.
Since diagnostic nslookups didn't return anything unusual as long as you'd configured your client to use Pi-hole for DNS, there is no real indication as to why it should fail when you configure Pi-hole for your entire network through your router.
So far, we have not examined how your router would actually do that.
It would be preferred to have your router distribute Pi-hole as local DNS server via DHCP. If instead it would only allow configuration of Pi-hole as its upstream DNS server, it may suppress Pi-hole's answers if DNS Rebind Protection is active for Pi-hole.
In that case, exempt Pi-hole from Rebind Protection (or disable it altogether if that's not possible).
No apology necessary.
I've been thinking about this and trying to digest your comment so I could reply with something coherent and not too much for you sift through. But, I'm a little confused about some of what you said.
Just to regroup, I'm not currently using the router other than the pihole and the macbook client are getting their IP's from the router, and ultimately the pihole would direct traffic through the router. But, the testing I have been doing has been to point the macbook's DNS to the pihole, which kinda eliminates some of the router issues you raised, doesn't it?
I have a Netgear X6 R8000. I tried to find some documentation on this and looked around the router settings. I didn't see anything on this.
I tried disabling the pihole with the pihole GUI. I thought that might rule out the pihole altogether. I'm not sure if it does rule it out, but it didn't allow my client to get to the internet either. So, I'm not sure if that gained insight.
Where does the traffic go after a query? Is there a log I can tail? I looked at /var/log/pihole.log and /var/log/pihole-FTL.log, but they don't seem to log queries, or at least I couldn't see any. Is there a debug or "very verbose" log I can enable? I'm a command line guy. So, command line tail -f or something is preferable to me over gui. Could there be anything stuck in the database? I don't really have anything I wouldn't mind losing. I have maybe a half dozen things I've whitelisted like sonos and amazon. I could refresh the databases if that would be diagnostic.
That sentence is hard to decode.
Any client on your network has to use your router as gateway, or they wouldn't be able to connect to anything on the Internet.
No.
Pi-hole handles DNS requests only.
Pi-hole doesn't redirect any traffic to your router, nor does it see traffic on your network other than DNS.
No, it rather precludes a set of potential router configuration issues from the analysis.
Once a client has resolved a name to an IP address, further communication will be between the client and that IP. Traffic to IP addresses outside your current network segment will be using your router as gateway.
I suspect something went wrong when you manually edited configuration files to switch your Pi-hole machine from WiFi to Ethernet, or maybe you assigned the same IP address twice (for both WiFi and Ethernet).
To reconcile, disable WiFi on your RPi 3, run pihole -r and Reconfigure for eth0. Check your RPi's IPv4 adddress with ip -4 address show eth0 and verify your router is using that address for DNS.
Yikes! I showed my networking ignorance.
That's what I meant. I just meant that was all it was doing. Sorry for the confusing choice of words.
The WiFI was already disabled, according to raspi-config. I ran the commands and updated the DNS on the router. This is what happens on the router.
Nobody else seems to have any ideas and you must be exhausted from helping me. If you're ready for me to uninstall and reinstall and see if that helps, I can do that.
Otherwise, there must be a piece that reconfigure doesn't touch. Just thinking out loud, what's the difference between installing and reconfiguring? Maybe that's the piece that's broken.
Now that I think understand a little better, maybe I can ask a better question. If the Pihole is resolving the DNS to an IP and it supposed to be giving the IP back to the client, it would seem like there would be a process, a config file or maybe a log or something that we could look at that handles that process.
Could the problem have anything to do with homebridge and the pihole not playing together nicely, like 2 instances of node.js or something that are in conflict? So, the pihole uses one to receive the query but the other to send the results back to the client? I don't know, I'm grasping for ideas. I already showed I don't understand this, too well.
We haven't communicated in quite a while now. But, I want to let you know that I tried uninstalling and reinstalling and just ended up breaking a lot stuff. Keep in mind this is on a Homebridge Pi. And, so, I just threw in the towel. I did a backup of my homebridge setup and just reflashed homebridge, restored that and then used the hb-config menu to reinstall pihole.
I want to thank you for sticking with me as long as you did. If you have any questions about my setup or what I did, let me know. We spent a ton of time trying to fix this. It probably only took an hour or so to rebuild my Homebridge/Pihole setup. That was clearly the fastest approach. But, I hate not knowing where I went wrong.
I think we can close this thread, unresolved.
This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.