But you didnt know untill you run the
"126.96.36.199#53 161 0" "188.8.131.52#53 4 0"
same stuff as you!
Currently in the DNS settings of Pi-hole, I have the IPv4 boxes checked for Google. But I've also tried OpenDNS, and checking the IPv6 boxes as well.
EDIT: just to be clear, I ran those commands on the Pi itself. That's what you intended right?
What if you run similar command on a client/the Mac:
nslookup -class=chaos -type=txt servers.bind 192.168.1.193
;; connection timed out; no servers could be reached
Do you have another client (MacOS, Windows or Linux) to run those same commands from?
If results are similar, I suspect some router setting/security feature blocking.
Also did you check below bit?
EDIT: Ow above applies to the Mac your using to test.
Yeah, I need to get it spun up, but I'll give it a go.
Nah, nothing that I know of.
Thanks for your help! Will report back shortly.
Check if got below or similar feature:
Yeah, that was one of my guesses too. I don't know how to tell though--Spectrum has locked down this router, and I can only see a fairly limited number of options on their setup app. (This is why I was trying to do this by setting DNS settings on the client, instead of messing too much more with the router, but it may not entirely sidestep the issue.)
Ok, this was surprising to me, but everything worked OK on my Ubuntu laptop. Guess there is something particular about my iphone/macbook. I'm pretty sure it's not Private Relay to blame because my OS is not updated :).
By themselves, your
nslookup results are inconclusive as to whether your Macbook's DNS requests would actually make it to your Pi-hole.
At least, the
nslookup through a public filtering DNS resolver returns the expected
flurry.com, indicating that your router is not redirecting DNS traffic to some resolver of its own devise behind the scenes.
Does that mean that the
nslookup pi.hole does not register at all in Pi-hole's Query Log?
Your debug log also shows Pi-hole is quite able to foward and resolve DNS requests, indicating that it has working upstream connectivity.
If your Macbook's loookup for
pi.hole is not making it to Pi-hole, this would suggest that something on that Macbook would interfere with DNS.
Do you run any antivirus software on that client?
Some antivirus software packages have a DNS feature (like AVG Secure DNS or AVAST Real-Site) that would force DNS through their own DNS servers, either by default or when they think they detect DNS issues (like Pi-hole blocking queries).
Hmm, I was looking in the "blocked queries" section, so I'm not sure, and now when I try to reproduce I'm having trouble getting any queries to show up.
I do not, to my knowledge. I at one point had Little Snitch installed, but it's not currently around.
Oh, also I think that it wouldn't show up anyway. I see something saying "Note: Queries for
pi.hole and the hostname are never logged."
This would again confirm that your observation is specific to your Macbook.
Pi-hole's replies may not make it back to your Macbook.
I've just been made aware that your Pi-hole has the same, identical IP assigned for
eth0 as well as
*** [ DIAGNOSING ]: Name resolution (IPv4) using a random blocked domain and a known ad-serving domain [✓] tf.nexac.com is 0.0.0.0 on lo (127.0.0.1) [✓] tf.nexac.com is 0.0.0.0 on eth0 (192.168.1.193) [✓] tf.nexac.com is 0.0.0.0 on wlan0 (192.168.1.193) [✓] doubleclick.com is 184.108.40.206 via a remote, public DNS server (220.127.116.11)
Identical IPs on different network adapaters will create all sorts of routing issues.
Each network interface must carry its own, unique IP address.
Assign a different IP for
wlan0 and see if your issue persists.
That's my Pi's IP I think, not my Macbook's? I ran the diagnostic script from the Pi.
But it is interesting nonetheless. I'm not entirely sure how to reserve a different IP for the different adapters though--is it possible to configure that on the device itself? Because Spectrum seems to only be giving me a single option.
Indeed, they are - I should not post after midnight.
The advice is still the same, though.
Commonly, router's tell devices apart by their MAC address, and each network interface carries its own MAC. Comparing the MAC as shown in your router to the ones listed for your RPi will tell you which one of it your router is aware of.
Manually setting a static IP on device is possible.
It is also more likely to introduce duplicate IPs by manually setting them, so you should definitely check your RPi for static IPs.
It would depend on your OS variety how exactly you'd configure a static IP.
For the current Raspberry Pi OS, you have a choice of using
NetworkManager (if you'd have opted for enabling
Assuming you kept with the defaults, you could check the contents of
This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.