I have pihole as dhcp and dns server on my network. It runs on 192.168.10.XXX subnet.
Everything works as expected.
For some experimentations I added a separate subnet, 192.168.12.XXX, with dd-wrt based router, whose WAN port is connected to 192.168.10.0 network.
Devices connected to 192.168.12.0 network can access the internet, can resolve public hostnames, can ping devices on 192.168.10.0 network.
They can't resolve names of devices on 192.168.10.0 network.
Update: The solution was to disable "No DNS Rebind" on dd-wrt.
For instance, when device connected to 192.168.12.0 issues a DNS resolve request to serverA, request is properly forwarded to pihole, and I see following lines in pihole logs:
Apr 21 12:40:02: query[A] serverA.home from 192.168.10.249 *(this is an address of dd-wrt router of the second network)*
Apr 21 12:40:02: /etc/pihole/custom.list serverA.home is 192.168.10.245 *(this is a correct address of serverA)*
Apr 21 12:40:02: query[CNAME] serverA.home from 192.168.10.249 *(have no idea what it is)*
Apr 21 12:40:02: config serverA.home is NODATA <- **apparently this indicates some problem**
Devices querying pihole directly, not via dd-wrt router (i.e. from 192.168.10.XXX network) can resolve everything as expected.
Same results happen if query is issued to serverA without "home" suffix.
DNS settings: Never forward non-FQDN A and AAAA queries - ON Never forward reverse lookups for private IP ranges - ON Use Conditional Forwarding - OFF
serverA has a static DHCP lease and is added to Local DNS Records.
there are no entries in Local CNAME Records.
Please upload a debug log and post just the token URL that is generated after the log is uploaded by running the following command from the Pi-hole host terminal:
Your debug log shows your Pi-hole to be operational.
In particular, it shows that there are indeed no CNAME definitions at all, so the query[CNAME] for serverA.home is answered correctly, i.e. that log line does not constitute an issue.
EDIT: I note that CNAME definitions would not be expected nor required for local hostnames. A records would be common for those, and the A query you shared is correctly answered by Pi-hole.
There are a number of A record definitions in your configuration that would point to 192.168.10.245, if for a different domain name.
I'm going to assume you've just obscured that domain in your posting, so Pi-hole's reply again would seem correct.
This is not denying your observation, just stating that the log lines you've shared so far fail to demonstrate your issue.
Run from a client in your 192.168.12.0/24(?) subnet, what is the output of
nslookup pi.hole
nslookup 192.168.10.244
nslookup <known-hostname>
Substitute <known hostname> with a name that you expect to resolve, but that you suspect to fail.
Currently I have only android clients, if that's not enough I can get some linux or windows clients, but it will take time.
nslookup pi.hole
--- Apr 21, 2023 14:56:00
--- IP (wlan0) 192.168.12.120
--- IP (rmnet1) 2a02:6680:2004:1d8e:ea:7258:8fe3:ffd8
--- Connection: WIFI
DNS records for pi.hole
DNS server: 192.168.12.249, port 53, UDP
A The DNS server has no records associated with this type.
CNAME The DNS server does not exist.
when I run dns request for 192.168.10.244
--- Apr 21, 2023 14:58:06
--- IP (wlan0) 192.168.12.120
--- IP (rmnet1) 2a02:6680:2004:1d8e:ea:7258:8fe3:ffd8
--- Connection: WIFI
DNS records for 192.168.10.244
DNS server: 192.168.12.249, port 53, UDP
A The DNS server does not exist.
CNAME The DNS server has no records associated with this type.
when I run dns request for "samsung":
--- Apr 21, 2023 14:53:04
--- IP (wlan0) 192.168.12.120
--- IP (rmnet1) 2a02:6680:2004:1d8e:ea:7258:8fe3:ffd8
--- Connection: WIFI
DNS records for samsung
DNS server: 192.168.12.249, port 53, UDP
A The DNS server has no records associated with this type.
CNAME The DNS server has no records associated with this type.
pi logs for samsung request:
Apr 21 14:53:04: query[A] samsung from 192.168.10.249
Apr 21 14:53:04: /etc/pihole/custom.list samsung is 192.168.10.240
Apr 21 14:53:04: query[CNAME] samsung from 192.168.10.249
Apr 21 14:53:04: forwarded samsung to 208.67.222.222
Apr 21 14:53:04: reply samsung is NODATA
For comparision, same request coming from another device:
Apr 21 15:19:12: query[A] samsung from 192.168.10.10
Apr 21 15:19:12: /etc/pihole/custom.list samsung is 192.168.10.240
Apr 21 15:19:12: query[AAAA] samsung from 192.168.10.10
Apr 21 15:19:12: config samsung is NODATA-IPv6
It's highly unusual that your nslookups would trigger a CNAME request.
Android devices are not the best platforms for analysing DNS issues.
Terminal apps often would use hardcoded DNS servers, ignoring the ones provided by your network.
That said, your Pi-hole did register the request for samsung, so your specific Android may behave correctly, or your dd-wrt router may forcefully redirect DNS requests to its upstream Pi-hole.
The replies provided by Pi-hole seem correct.
Again, the A request is answered with the correct IP:
However, the reply as received by Android does not match that:
This would suggest that the DNS reply has been blocked (or manipulated) on its way from Pi-hole back to your Android.
The natural suspect would be your dd-wrt router at 192.168.10.249, which your Android output shows as having been used as DNS server for the nslookup.
maybe I confused you with two log samples:
When I send this from android device, connected to dd wrt router, I got no response (resolve failed), and here you can see why - pihole sent it to upstream server.
In this example, when I send request from the same device when it is connected to pihole network,
Apr 21 15:19:12: query[A] samsung from 192.168.10.10
Apr 21 15:19:12: /etc/pihole/custom.list samsung is 192.168.10.240
Apr 21 15:19:12: query[AAAA] samsung from 192.168.10.10
Apr 21 15:19:12: config samsung is NODATA-IPv6
resolving succeeded and device got a proper IPV4 address.
I assume the "root cause" of dns resolving failure is pihole's attempt to resolve it with public dns server. How it can be related to the fact that this query arrives via dd-wrt router - I don't know.
No.
You can't compare different type requests (AAAA vs. CNAME).
That second nslookup triggered an A and an AAAA request (as would be expected for nslookup - as mentioned, it is highly unusual for nslookup to trigger a CNAME request).
For the A requests, your log excerpts show a consistent output:
They are always answered identically and correctly, as can be seen by
However, your Android client never sees that reply as supplied by Pi-hole.
Instead, it reports the reply for the A record request as:
or
The reply itself doesn't make much sense, as an A record does not query for a DNS server, but for known IPv4 addresses for a given domain.
In addition, the DNS server used for that nslookup is explicitly shown as:
There's something highly unusual about that nslookup, both in the way it sends its requests as well as in the way it presents replies.
That's probably worth investigating, but the issue is quite clear:
Something blocks or manipulates the DNS replies as supplied by Pi-hole.
