[Feature Request] Local Host Resolution by Network

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.

Debug Token:


I do understand that entering these into the /etc/hosts file would help resolve this however this only works for devices local to the 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,,, and 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

Hello Mcat12,

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


This is functionally the same as --server, but provides some syntactic
sugar to make specifying address-to-name queries easier. For example
--rev-server=, is exactly equivalent to


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’m not sure what I’m doing wrong with the creation or format of this file.

Check the logs using these commands:

journalctl -u pihole-FTL
less /var/log/pihole.log
less /var/log/pihole-FTL.log

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.


Only when entering this line do I see the following in the logs and PiHole not starting correctly.


Jul 02 21:56:35 pihole.walpurgis.night pihole-FTL[647]: dnsmasq: bad prefix at line 2 of /etc/dnsmasq.d/02-pihole.conf

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.

dnsmasq only supports the following prefix lengths: 8, 16, 24, 32. The line


specifies a netmark of /12 which is not allowed. This has nothing to do with your last assumption.

This is documented in the dnsmasq man page (albeit poorly and only under the option domain):

If the address range is given as ip-address/network-size, then a additional flag “local” may be supplied which has the effect of adding local declarations for forward and reverse DNS queries. Eg.


is identical to


The network size must be 8, 16 or 24 for this to be legal.

It would be easy to allow /12 (or even any arbitrary mask!), however, it is a feature request that needs to be addressed by dnsmasq not pihole-FTL (we follow a minimal modifications of dnsmasq policy).
I checked how it is currently implemented and realized that dnsmasq uses a quite clever trick to simplify the task significantly. Unfortunately, this trick - going from in-addr.arpa downwards in “subdomains” - ultimately prevents any netmask that is not a multiple of 8. Allowing something like /12 would require a complete rewrite of the entire algorithm used here.

1 Like

Thanks for the explanation. Seems there is quite a bit going on here behind the scenes. I could split up the /12 so it falls in line with this requirement for dnsmasq.