It's going to the same place, just with a direct address to the router. If you run this same command without the "@...", do you also get a valid response? Run this both from the Pi terminal and from a client (may need to use nslookup on your client, depending on OS).
I don't think it is going to the same place. Without the @10.1.1.1, I'd hit 10.1.1.2, which is pi-hole. That's what's dropping the connection. I can test this by running dig somedomainintheblocklist.com and dig samedomain.com @10.1.1.1 while everything is working, and the first one will return 0.0.0.0, while the other one will return the proper A records.
By the way, when I say I run dig, I mean I'm always running from a client.
You are correct. Eventually they should get to the same place, but with the @ it does not route through the Pi-Hole to get to the router. What does the tail of your pihole.log show for the request - did it go to the router and not get a reply from the router?
From the Pi terminal, when you run the dig (with and without the @ modifier), do you get the same results?
Running dig youtube.com from a client:
;; communications error to 10.1.1.2#53: connection reset
Running dig youtube.com @10.1.1.1 from the same client:
;; ANSWER SECTION: youtube.com. 55 IN A 216.58.202.78
Running dig youtube.com from the pi:
;; communications error to 127.0.0.1#53: connection reset
Running dig youtube.com @10.1.1.1 from the pi:
;; ANSWER SECTION: youtube.com. 55 IN A 216.58.202.78
pihole status shows DNS service is running.
There is indeed a pihole-FTL process running, and using some 5% CPU.
Output of tail /var/log/pihole.log:
Oct 5 15:42:09 dnsmasq[1192]: 28255 10.1.1.116/57410 reply usmia.ce.apple-dns.net is 17.248.137.136
Oct 5 15:42:09 dnsmasq[1192]: 28255 10.1.1.116/57410 reply usmia.ce.apple-dns.net is 17.248.184.72
Oct 5 15:42:09 dnsmasq[1192]: 28255 10.1.1.116/57410 reply usmia.ce.apple-dns.net is 17.248.184.16
Oct 5 15:42:09 dnsmasq[1192]: 28255 10.1.1.116/57410 reply usmia.ce.apple-dns.net is 17.248.137.113
Oct 5 15:42:10 dnsmasq[1192]: 28456 10.1.1.1/27428 query[PTR] 4.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.4.0.0.0.0.0.f.0.4.b.1.1.0.0.2.ip6.arpa from 10.1.1.1
Oct 5 15:42:10 dnsmasq[1192]: 28456 10.1.1.1/27428 forwarded 4.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.4.0.0.0.0.0.f.0.4.b.1.1.0.0.2.ip6.arpa to 10.1.1.1
Oct 5 15:42:10 dnsmasq[1192]: 28457 10.1.1.120/49531 query[AAAA] pi.hole from 10.1.1.120
Oct 5 15:42:10 dnsmasq[1192]: 28457 10.1.1.120/49531 /etc/pihole/local.list pi.hole is fd00::20
Oct 5 15:42:10 dnsmasq[1192]: 28458 10.1.1.120/58730 query[A] pi.hole from 10.1.1.120
Oct 5 15:42:10 dnsmasq[1192]: 28458 10.1.1.120/58730 /etc/pihole/local.list pi.hole is 10.1.1.2
Ok. I think one of the devs will have to look at this. I don't see anything obvious in your debug log.
Just for testing, change your upstream DNS for the Pi-Hole to one of the commercial servers instead of the router.
Did you allow inbound requests on your pfsense on port 53 ?
See if a tcp request on the client will pull results:
dig +tcp youtube.com
From the LAN side, yes. I can set my DNS to 10.1.1.1 on any machine and DNS resolution works all the time.
Using pfSense as my DNS, I can run a tcp request and get a valid answer.
What about the same dig tcp request on the device with Pi-hole, or a client set with 10.1.1.2 as the DNS.
To eliminate any issues, I just did a clean install - reflashed raspbian, updated everything to the latest version, added a static ipv6 (fd00::20) and installed pi-hole.
After importing my blocklists (about 70 of them), DNS stopped working again.
From a client with pi-hole set a DNS (both ipv4 and v6):
dig +tcp youtube.com
;; communications error to fd00::20#53: connection reset
and again to make sure, with this output:
;; communications error to 10.1.1.2#53: connection reset
(Notice both ipv4 and ipv6 were tried and both failed).
However, without the +tcp, I'm getting a response.
From the raspberry pi running pi-hole, I get the same error:
;; Connection to 127.0.0.1#53(127.0.0.1) for youtube.com failed: connection refused.
Without the +tcp, it's running fine, getting a response from pfSense (the LAN IPv6).
Let's narrow this down even further.
Revert to the default blocklists and try again:
https://discourse.pi-hole.net/t/how-can-i-restore-pi-holes-default-ad-lists/4683/3?u=ramset
What happens if you don't set the IPv6 fd00 address?
I have had much frustration with my pfSense and Pi-hole when I tried adding ULAs to my setup.
Okay, I've reverted to the default lists. Let's see if that works. I ran pihole restartdns and now dig +tcp returns a proper response.
As for the ULA, if I don't add it, pfSense will give out some IP for DNSv6. It's going to be its LAN IPv6, which has two problems associated: one, it bypasses pihole; two, it changes every 36 hours because my ISP is stupid, but the DNS doesn't seem to change with RA.
There must be something in one or several of your lists (if not the sheer amount of blocked domains - 4.568.377 entries - that overload and crash your raspberry pi).
The pfSense forums https://forum.pfsense.org have several posts on ULAs and I have tried about everything they have suggested but the problems they encountered keep biting me too. The best suggestion was from one of the staff folks that suggested abandoning the ISP's flaky IPv6 and getting a stable and usable tunnel from HE and using that.
My ISP, Cox Cable, seems to have gotten the PD (Prefix Delegation) sorted out well enough that I haven't had to go that route. I will be adding a cron script to watch for PD changes and update the Pis if that does happen. See the first post here: Use IPv6 ULA addresses for Pi-hole
The suggestion later by spacemonkey did not work out for me.
Thing is, I can always ping pi-hole, both v4 and v6, and I can also ssh into it, and access the web interface. The only thing that stops working is the DNS resolver, so I don't think it is IPv6 related.
Just tested now and, with the default lists only, it looks like we're still good, almost 24 hours later. However, those were some very low traffic 24 hours. I'll make sure to keep you guys posted if this changes or not. I'll try to add a few extra lists in the following days as well to test it out as well.
What's weirder is that neither CPU nor memory usage seemed to go up...
Anyway, thanks for all the help guys, I really appreciate it.
For what it's worth, when I loaded all your blocklists into a Pi Zero (replacing all the existing blocklists), the Pi-Hole on the Zero failed immediately. Couldn't connect to API, showed 2 domains blocked, basically a dead halt. I had to reboot to remove the gravity list.
Well, I'm running on a rPi 3B+, but still, I might have overdone it a bit.
This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.