Can't Resolve DNS for other subnets

srelliott · May 14, 2025, 2:57am

I upgrade Pi-Hole to version 6 and started having various strange issues with DNS.

I have a Unifi Dream Machine SE UDMSE that serves up DHCP on 192.168.x.1, where X is 1 through 5. I can successfully nslookup on server 192.168.1.1 for any of the fqdn or friendly names on all subnets. However, I can only do a reverse lookup for the 192.168.1.x network. 192.168.2.x - 192.168.5.x do not resolve. If I jump onto the UDM SE (ssh 192.168.1.1) it can resolve all reverse lookups with the server set to 127.0.0.1 or 192.168.1.1.

I also noticed that pihole seems to block traffic from 127.0.0.1 as well as my other subnets. I don't know if that's normal or if it started happening after the upgrade. See attached screen shot.

I also tried to setup conditional forwarding as for some reason, my pihole /etc/hosts file only resolves 192.168.1.x names and puts in the IP for all the other subnets in the query log.

Conditional Forwarding Rules
true,192.168.1.0/24,192.168.1.1,local
true,192.168.2.0/24,192.168.1.1,local
true,192.168.3.0/24,192.168.1.1,local
true,192.168.4.0/24,192.168.1.1,local
true,192.168.5.0/24,192.168.1.1,local

I know this is a lot and it truly feels hopeless. Thanks in advance.

srelliott · May 14, 2025, 2:59am

srelliott · May 14, 2025, 3:00am

Where pc_ryan is a 192.168.1.x subnet.

srelliott · May 14, 2025, 3:06am

I've seen others ask for this debug log so here is mine:

https://tricorder.pi-hole.net/nEwNFuIh/

Bucking_Horn · May 14, 2025, 6:35am

Your debug log shows that your router is distributing local as local domain.
You should note that .local is the TLD reserved for the mDNS protocol, and should not be used with plain DNS. Doing so would cause unnecessary additional network traffic and potentially confuse you when DNS and mDNS would yield different resolution results
You should reconfigure your router to use one of the TLDs reserved for home network usage, like .internal, .lan or .home.arpa.

Your Conditional Forwarding rules look ok in your debug log.

You could verify how your router at 192.168.1.1 answers reverse lookups, by running respective nslookups from your Pi-hole machine, e.g.

nslookup 192.168.2.209 192.168.1.1

That would reveal if your router knows a name for 192.168.2.209.

But your screenshots already show that PTR requests are blocked by Pi-hole.
Apparently, you've configured a regex rule with id 99, labeled as TLDs to block arpa requests, effectly denying all reverse lookup resolution, including public ones.

At the same time, you've only added a single rule to allow 192.168.1.0/24 lookups ^.*\.1\.168\.192\.in\-addr\.arpa$, with id 91 and label ARPA Local.

In order for PTR reverse lookups to succeed again (not just your local ones), you should remove arpa from your blocklist.

srelliott · May 15, 2025, 12:09am

Thank you for your response and knowledge into .lan versus .local - I' have corrected that issue along with the .arpa being blocked. It's very odd, this was all working perfectly before the upgrade to 6.

Things seem to be a bit better now, however, I'm having an interesting issue...

On the pihole itself (192.168.5.2) all NSLOOKUPS work:

> simba
Server:         192.168.5.2
Address:        192.168.5.2#53
Name:   simba
Address: 192.168.2.226

> pc_ian
Server:         192.168.5.2
Address:        192.168.5.2#53
Name:   pc_ian
Address: 192.168.2.226

> simba.lan
Server:         192.168.5.2
Address:        192.168.5.2#53
Name:   simba.lan
Address: 192.168.2.226

> 192.168.2.226
226.2.168.192.in-addr.arpa      name = simba.

On the windows box (192.168.1.50) nslookup can't lookup the aliases:

> simba
Server:  pi.hole
Address:  192.168.5.2
*** pi.hole can't find simba: Non-existent domain

> pc_ian
Server:  pi.hole
Address:  192.168.5.2
*** pi.hole can't find pc_ian: Non-existent domain

> simba.lan
Server:  pi.hole
Address:  192.168.5.2
Name:    simba.lan
Address:  192.168.2.226

> 192.168.2.226
Server:  pi.hole
Address:  192.168.5.2
Name:    simba
Address:  192.168.2.226

The /etc/hosts file on pi-hole (192.168.5.2)

192.168.2.226 simba simba.lan pc_ian

Latest debug log: https://discourse.pi-hole.net

Thanks again!!

rdwebdesign · May 15, 2025, 12:15am

You posted the wrong link to the new log. Please generate a new one

srelliott · May 15, 2025, 2:15am

Doh! Been a long day.

https://tricorder.pi-hole.net/jPRIqhgB/

Bucking_Horn · May 15, 2025, 8:18pm

Likely unrelated to your observation, your most recent debug log shows you are still blocking arpa, but you've just added more allow rules for your respective local subnets. This means that legit reverse lookups for public IPs still won't work.

As for your unsuccessful Windows nslookup results:
How do they register in Pi-hole's Query Log?

srelliott · May 16, 2025, 2:44am

Thanks for having me look at the query log. Figured out that the .local was sticking despite /flushdns and /release /renew and a nbtstat /R. Once I rebooted, .lan took to the Windows device and that resolved that issue. I removed AARP instead of ARPA, that was indeed blocking nslookup for public IPs. - Still don't know why my old configuration was working on version 5.

In any case, I apparently should stop trying to be an IT tech after 14 hours of work. - Doh! lol

I see a potential issue with the localhost. When I "Expand hostnames" in DNS, I see this:

It adds the .local -- when I turn on enable "Expand hostnames" in the Pi-hole DNS settings. When I turn it off it removes the .local

I just want to double check that isn't an issue. I've set the domain to .lan on the UDM SE gateway (192.168.1.1). The domain is set to "none" on pi-hole (192.168.5.2).

root@pihole:/etc# hostname -d
root@pihole:/etc# domainname

From the pihole:

> server 192.168.5.2
Default server: 192.168.5.2
Address: 192.168.5.2#53
> 192.168.5.2
2.5.168.192.in-addr.arpa        name = pi.hole.
> 127.0.0.1
1.0.0.127.in-addr.arpa  name = localhost.
> server 192.168.1.1
Default server: 192.168.1.1
Address: 192.168.1.1#53
> 192.168.5.2
2.5.168.192.in-addr.arpa        name = pihole.lan.

Just want to make sure I still don't have something misconfigured. And thank you so much for all the help. I really felt it was hopeless at first.

srelliott · May 16, 2025, 4:00am

Should also mention:

> pihole.local
Server:         192.168.5.2
Address:        192.168.5.2#53

Name:   pihole.local
Address: 192.168.5.2
Name:   pihole.local
Address: fe80::4c29:4326:8729:32c6

srelliott · May 23, 2025, 3:08am

Are this the expected results?

> server 192.168.5.2
Default server: 192.168.5.2
Address: 192.168.5.2#53

> 192.168.5.2
2.5.168.192.in-addr.arpa        name = pi.hole.
> 127.0.0.1
1.0.0.127.in-addr.arpa  name = localhost.
> server 192.168.1.1
Default server: 192.168.1.1
Address: 192.168.1.1#53

> 192.168.5.2
2.5.168.192.in-addr.arpa        name = pihole.lan.

> pihole.local
Server:         192.168.5.2
Address:        192.168.5.2#53
Name:   pihole.local
Address: 192.168.5.2
Name:   pihole.local
Address: fe80::4c29:4326:8729:32c6

Bucking_Horn · May 23, 2025, 5:55am

Please provide a fresh debug token.

srelliott · May 23, 2025, 12:58pm

https://tricorder.pi-hole.net/SYJs9hfx/

Thank you.

Bucking_Horn · May 24, 2025, 6:40am

That isn't the case.
Your debug log shows your Pi-hole's domain name as local (accessible via Settings|DNS :

domain = "local" ### CHANGED, default = "lan"

srelliott · June 1, 2025, 10:52pm

Just got back from a week long vacation. You are absolutely right. Fixed the domain on Pi-hole and DNS is returning as expected. I seriously appreciate your help in resolving these issues. I really felt it was hopeless at first. Looks like we have smooth sailing once again. Best wishes!

system · June 22, 2025, 10:52pm

This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.