No DNS requests resolve on client computer when using per-device DNS setup

[deHakkelaar]

@lswainemoore

Apologies if this is a silly question, but is that good or bad?

Apologies accepted
Thats not an easy question to answer.
Some say you need to run a firewall on every system.
Some say if you know what ports are listening, you wont need one.

@lswainemoore

am I supposed to have set that up before running the install script?

Before or after doesnt matter (before is preferred).
But as soon as you want to make use of the Pi-hole service, those required ports need to be allowed on any firewalls that sit between your clients and Pi-hole.

Pi-hole is not gona touch your firewall as there are many firewall tools available and many ways to setup a firewall.

[lswainemoore]

@deHakkelaar

Before or after doesnt matter (before is preferred).
But as soon as you want to make use of the Pi-hole service, those required ports need to be allowed on any firewalls that sit between your clients and Pi-hole.

Huh, but if I've got no firewall, which the earlier results showed, that means it's not a necessary step, right? Putting security aside for the minute, in the interest of just getting things working. So my failing to do that wouldn't be the issue at hand?

For context, I'm setting all this up on a brand new Pi.

[deHakkelaar]

@lswainemoore

> nslookup flurry.com 192.168.1.193
;; connection timed out; no servers could be reached

Above could also be the upstream configured DNS servers for Pi-hole not responding.
What DNS server(s) is/are configured in Pi-hole?

dig +short @localhost chaos txt servers.bind

And what if you try to query those from the Raspi:

dig @<DNS_SERVER_IP> flurry.com

Eg:

pi@ph5b:~ $ dig @8.8.8.8 flurry.com

; <<>> DiG 9.16.22-Raspbian <<>> @8.8.8.8 flurry.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11375
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;flurry.com.                    IN      A

;; ANSWER SECTION:
flurry.com.             300     IN      A       98.136.103.23
flurry.com.             300     IN      A       212.82.100.150
flurry.com.             300     IN      A       74.6.136.150

;; Query time: 29 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Wed Feb 22 22:30:30 CET 2023
;; MSG SIZE  rcvd: 87

[deHakkelaar]

@lswainemoore

Huh, but if I've got no firewall, which the earlier results showed, that means it's not a necessary step, right?

Indeed.
But you didnt know untill you run the iptables command

[lswainemoore]

@deHakkelaar

But you didnt know untill you run the iptables command

Gotcha!

[lswainemoore]

@deHakkelaar

dig +short @localhost chaos txt servers.bind

"8.8.8.8#53 161 0" "8.8.4.4#53 4 0"

@deHakkelaar

dig @<DNS_SERVER_IP> flurry.com

same stuff as you!

@deHakkelaar

What DNS server(s) is/are configured in Pi-hole?

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?

[deHakkelaar]

@lswainemoore

That's what you intended right?

Right.

What if you run similar command on a client/the Mac:

nslookup -class=chaos -type=txt servers.bind 192.168.1.193

[lswainemoore]

Cool.

@deHakkelaar

nslookup -class=chaos -type=txt servers.bind 192.168.1.193

;; connection timed out; no servers could be reached

[deHakkelaar]

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?

@nprampage

Are you running any Security software, like an antivirus package (AVG, Norton, McAfee, for example) on this device? Some of these may have a firewall or DNS component that's getting in the way. Just a thought.

EDIT: Ow above applies to the Mac your using to test.

[lswainemoore]

@deHakkelaar

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.

Yeah, I need to get it spun up, but I'll give it a go.

@deHakkelaar

Also did you check below bit?

Nah, nothing that I know of.

Thanks for your help! Will report back shortly.

[deHakkelaar]

Check if got below or similar feature:

Why won't Pi-hole work with DNS rebind protection enabled?

What is DNS rebind protection? If your router has an option called DNS rebind protection enabled, you may run into issues when trying to use Pi-hole as your DNS server. The reasons for this are quite technical, but to summarize what this option does in one sentence: DNS rebind protection does not allow DNS queries to be answered with a local IP address. Why does this interfere with Pi-hole? DNS rebind is meant to be a countermeasure to an attack on your network. So in many cases, it's ac…

[lswainemoore]

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.)

[lswainemoore]

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 :).

[Bucking_Horn]

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 0.0.0.0 for flurry.com, indicating that your router is not redirecting DNS traffic to some resolver of its own devise behind the scenes.

@lswainemoore

Noting that I see flurry.com in the Pi's admin interface for the second one.

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).

[lswainemoore]

@Bucking_Horn

Does that mean that the nslookup pi.hole does not register at all in Pi-hole's Query Log?

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.

@Bucking_Horn

Do you run any antivirus software on that client?

I do not, to my knowledge. I at one point had Little Snitch installed, but it's not currently around.

[lswainemoore]

@Bucking_Horn

Does that mean that the nslookup pi.hole does not register at all in Pi-hole's Query Log?

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."

[Bucking_Horn]

@lswainemoore

Ok, this was surprising to me, but everything worked OK on my Ubuntu laptop.

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 wlan0 :

*** [ 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 142.250.72.110 via a remote, public DNS server (8.8.8.8)

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.

[lswainemoore]

That's interesting!

@Bucking_Horn

I've just been made aware that your Macbook has the same, identical IP assigned for eth0 as well as wlan0

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.

[Bucking_Horn]

@lswainemoore

That's my Pi's IP I think, not my Macbook's?

Indeed, they are - I should not post after midnight.
The advice is still the same, though.

@lswainemoore

Spectrum seems to only be giving me a single option.

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.

@lswainemoore

is it possible to configure that on the device itself?

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 dhcpcd or NetworkManager (if you'd have opted for enabling NM via raspi-config).

Assuming you kept with the defaults, you could check the contents of /etc/dhcpcd.conf.