DNS Name Resolution on /23

Please follow the below template, it will help us to help you!

Hello!
First of all, thank you for Pi-hole! Making my life a lot better without ads!

I've recently "upgraded" my network from a /24 to a /23 subnet, as I needed some extra address space.
However, after the update, I did not see hostname resolution for the 192.168.3.0 range. In the 192.168.2.0 range, I did get all the hostnames resolved properly.

I have set all my hostnames in dnsmasqd/02-home.conf, which is where I keep track of all my services for DNS name resolution, to ensure that I am not bound by IP Addresses.

After researching the issue, I was pointed to this topic, that seems to be around the same issue.

I have no added the following lines in my 02-home.conf, but that seems more like a work-around than an actual solution.

rev-server=192.168.2.0/24,192.168.2.1
rev-server=192.168.3.0/24,192.168.2.1

192.168.2.1 is my USG, which is the upstream also set in Conditional Forwarding.

Expected Behaviour:

Pi-hole should resolve DNS Names properly on 192.168.3.0

Pi-hole runs in Docker:

  • Docker Tag 2022.11.2
  • Pi-hole v5.14.2
  • FTL v5.19.2
  • Web Interface v5.17

Actual Behaviour:

Pi-hole does not find the correct DNS names on 192.168.3.0

Debug Token:

Debug Log without the two lines in 02-home.conf:
https://tricorder.pi-hole.net/81eqoLsG/

Debug Log with the two lines in 02-home.conf:
https://tricorder.pi-hole.net/WEruCm3h/

Please let me know if you need anything else :slight_smile:

You set your DHCP range on Pi-hole to:

    DHCP_START=192.168.1.1
    DHCP_END=192.168.1.254
    DHCP_ROUTER=192.168.1.1

I don't use Pi-hole DHCP server. Not sure why that is there. I might have set that once, but never removed it.

Since your Pi-hole is already holding the definitions for local hostnames, there would be no need for any Conditional Forwarding at all.

Could you elaborate where and how you do 'not see hostname resolution for the 192.168.3.0 range'? Some example lookups would also be helpful.

Your debug log shows your router to distribute two DNS servers:

*** [ DIAGNOSING ]: Discovering active DHCP servers (takes 10 seconds)
   Scanning all your interfaces for DHCP servers
   
   * Received 304 bytes from eth0:192.168.2.1
     Offered IP address: 192.168.2.18
     DHCP options:
      Message type: DHCPOFFER (2)
      Offered IP address: 192.168.2.18
      netmask: 255.255.254.0
      router: 192.168.2.1
      dns-server: 192.168.2.18
      dns-server: 192.168.2.19

The Pi-hole we're talking about resides at 192.168.2.18.

For that additional DNS server at 192.168.2.19 (regardless whether that would be another Pi-hole or some other DNS resolver):
Would that also be aware of your 192.168.3.0/24 range hostnames?

Oh, that's interesting :slight_smile:

The Conditional Forwarding is probably a hold-over from before, when I did not have that. Thought that was always necessary.
So I could basically turn Conditional Forwarding off?
What about Never forward non-FQDN A and AAAA queries (Currently disabled) and * Never forward reverse lookups for private IP ranges* (Currently enabled)?

The Second DNS Server (on .19) is another Pi-hole, which I turned off for this test, to ensure that all traffic went through the one I needed.
The two Pi-holes are kept in sync using gravity-sync, and have the same settings, so it is also aware of the 192.168.3.0/24 range.

I did not see the hostname resolution on the Query Log. That would show proper hostnames before, but not necessarily the ones I defined, because I guess it would get that from the router then.
Doing nslookup's from my machines actually work fine, it's just that the Query Log wouldn't show it.

Also, since the change, I'm also seeing more of these:

2022-12-08 09:45:56 	PTR	1.2.168.192.in-addr.arpa	localhost	OK (answered by 192.168.2.1#53)	DOMAIN (0.8ms)	
2022-12-08 09:45:56 	PTR	16.2.168.192.in-addr.arpa	localhost	OK (answered by 192.168.2.1#53)	NXDOMAIN (5.5ms)	
2022-12-08 09:45:56 	PTR	3.3.168.192.in-addr.arpa	localhost	OK (answered by 192.168.2.1#53)	NXDOMAIN (5.6ms)	
2022-12-08 09:45:56 	PTR	3.3.168.192.in-addr.arpa	localhost	OK (answered by 192.168.2.1#53)	NXDOMAIN (5.3ms)

Which also has to do something with resolution? Not sure if it's related, but it stuck out.

Sorry to bump :slight_smile:
But still wondering about this

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