Would it be possible to add a checkbox in the DHCP web admin page to block DHCP from allocating IP addresses to unknown hosts (i.e. those without a MAC address in the "Static DHCP leases configuration" table)?
I'm currently implementing this function through the addition of a custom conf file:
/etc/dnsmasq.d/43-disallow-unknown-hosts.conf:
dhcp-ignore=tag:!known
but a checkbox in the webadmin page would make the presence of this setting a lot more visible.
Thanks
What is the goal you want to achieve? We want to keep the web interface as simple, clear and easy to use as possible. Keep in mind that many/most Pi-hole users still do this as their first Raspberry Pi and/or networking project.
I'm afraid this feature may give a false sense of security as it "secures" your network against "foreign intruders" while it does not. You'll need a router that is able to "close" the port for unknown MAC addresses. The mere absence of automatic address configuration does not prevent any "intruder" from just configuring a valid manual configuration. It is made a bit more tricky as you first have to find the router's IP address but you can easily automate this by iterating.
You may very well know all this but the question is how to add such a feature without leading users into the aforementioned false sense of security...
Hi,
What is the goal you want to achieve?
Excellent question that more people should ask 
I'm just trying to raise the security bar a little by denying DHCP access to unknown hosts. Yes, I'm aware that a more-than-casual intruder can easily circumvent the absence of DHCP by assigning a static config but that requires a higher level of knowledge than the average user possesses, I suspect. I wholeheartedly agree that how this option is described to a non-technical user, so as not to give a false sense of security, could be tricky.
This request came about after my wife mistakenly gave out our LAN WiFi password (instead of our Guest WiFi password!) to a bunch of friends who subsequently connected their devices to our private LAN. Having this feature more readily available may have encouraged me to tick the checkbox and prevent casual users joining our network. As it happens, I've now enabled the feature via a custom dnsmasq conf file, giving me confidence that this particular "attack" won't happen again.
Taking onboard your very valid desire to keep the GUI as simple as possible (something I really appreciate, BTW), would it be possible to have this option available through an "Advanced Settings" tab?
Perfectly happy for the response to my request to be a "No" and that this option remain the preserve of "expert" users and dnsmasq conf files. I just thought I'd bring it up for discussion to see what the general consensus was.
I guess your request is fine and adding this option to Pi-hole seems worth it. Let's postpone the "how" (in GUI terms) a little but, just add the functionality in the "experts" range. You may know that Pi-hole is currently in a public beta phase for the upcoming Pi-hole v6.0 and I think we can still squeeze this feature in.
If you want to try it, follow the link above and switch to the beta branches, then switch to the new FTL branch
pihole checkout ftl new/dhcp_ignoreUnknownClients
and you will see a new option in the web interface under "all settings":
You need to be in "Expert" mode to see this option.
Just something to be aware of, when bringing a new device online (for which you don't yet know the MAC), this might cause frustration. I always keep a small pool of dynamics even though, once established, all my devices are explicitly assigned.
I tried to bring precisely this message across in my last sentence (see the screenshot), do you think this needs rewording? (always keep in mind that I'm not a native speaker, any feedback is always appreciated)
I think the wording is good and sufficient. Sometimes no matter how much you caution, people will fail to read and still complain later. 
The feature has been merged, no need to check out any special branch. Please go back to development-v6 in case you switched branches to continue receiving future updates.
