Please follow the below template, it will help us to help you!
It seems Pi.Hole is aware of the ability to resolve hosts local to it. I would like to give it a list of networks or it just all RFC private subnets, the Pi.Hole will attempt to resolve them for it's logs and conditional forwarding.
Expected Behaviour:
All private IP ranges entered into a setting on the Pi.Hole will attempt to resolve any lookups seen from devices on these networks to domains. Reverse lookups seen for these private subnets are sent to the conditional forwarder.
Actual Behaviour:
Only hosts that are local to the Pi.Hole are resolved.
I do understand that entering these into the /etc/hosts file would help resolve this however this only works for devices local to the 172.16.0.0 network and static devices on other networks. However non-static devices on any other subnet does not get resolved. The feature request is either a text box where desired subnets could be entered to forward to the configured conditional forwarding server. Or all RFC compliant networks, 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16 could be forwarded to the conditional forwarder.
Are you aware of the conditional forwarding setting that is already implemented? It is more limited than what you propose, but it currently supports forwarding subnets such as 192.168.1.1/24.
I have configured the conditional forwarder with the local DNS server beforehand. The pi-hole is able to resolve not only it's own name but also the DNS servers name. Both of these devices live on the 172.16.0.0/28 network. This is a server LAN designed to keep these devices safe and only allows access to ports that are required for day to day operations. This resolution is working as intended.
The issue I have found and the root of this request is that the pi-hole does not resolve the names for clients or any reverse lookups for private subnets that are not on the same network the pi-hole is located on. For example devices on the 10.10.10.0/24 subnet that use the pi-hole as it's primary DNS server do not get their names resolved on the clients list.
While this feature request is still a request (unimplemented), you can make a config in /etc/dnsmasq.d and use the rev-server option:
--rev-server=<ip-address>/<prefix-len>,<ipaddr>[#<port>][@<source-ip>|<interface>[#<port>]]
This is functionally the same as --server, but provides some syntactic
sugar to make specifying address-to-name queries easier. For example
--rev-server=1.2.3.0/24,192.168.0.1 is exactly equivalent to
--server=/3.2.1.in-addr.arpa/192.168.0.1
I created a file called 02-pihole.conf in /etc/dnsmasq.d with the following contents and found that the Pi-Hole service no longer started. Am I supposed to create a seperate file like this or should I append it to the install file mentioned in 01-pihole.conf? No worries, I took a snapshot of the instance before making these changes, I've since rolled it back.
The proper way is as you did, adding a new config file in /etc/dnsmasq.d. However, the settings you added are invalid:
The format of [the config] file consists of one option per line, exactly as the long options detailed in the OPTIONS section but without the leading "--".
I made another attempt creating the 02-pihole.conf in /etc/dnsmasq.d/ location. This time I created the file with the three lines without the "--" at the beginning. The result was the same, after rebooting, the pihole service could not start. I've since reverted the instance to before the changes were made.
I have figured it out. When the 172 entry is included in the file, PiHole will not initialize. Remove it and everything will work as expected. Currently I have the two entries below in the file without issues.
Since that fixed the issue, I now am curious as to why the 172 entry causes this. Could this be a bug with dnsmasq? Or pihole itself? Or is this expected since the network defined overlaps the server that is going to be resolving the network.
