I recently (and finally) upgraded my home network to a UniFi system after years of consideration and an incorrect assumption it would cost a small fortune to enact. My existing "core" router was reaching the end of its normal life, though, and I wanted a real mesh network with better outdoor coverage instead of using the range extender during the "not winter" months and connecting to a different SSID.
I had been using Pi-hole for DHCP and DNS with the old network setup with great success, and I wanted to continue using Pi-hole where it would best fit in the new environment. After the initial setup of the new network gear, I spent time curating a set of VLANs and firewall rules to better isolate the different use cases and traffic/access, including separate SSIDs for the different VLANs. All VLANs were set up to use UniFi for DHCP, but were pointing at Pi-hole for DNS. This DHCP transition and decoupling took some effort due to the various moving parts (including reassigning certain fixed addresses all the IoT devices to a new SSID), but it wasn't terrible. I wound up with this list of networks:
All was stable and working as expected, but a couple days afterward I noticed the problem in Pi-hole's interface: for all of the networks/subnets not having DHCP served by the Pi-hole, I had no reverse lookup of devices and just saw IP addresses. BOO.
A DNS Workaround
If I manually added local DNS records for the different VLAN devices, I could get human-understandable associations, but since I am using dynamic addresses for most devices that is not a sustainable practice, and I don't want/need/care to register everything in DHCP just for the sake of lookups.
Overthinking the Problem
As I stewed on a good way to solve this, I had several ideas...
- Dropping the Pi-hole completely (bad idea, since I am invested in its setup with nuanced rules for different devices/classifications);
- Setting up Pi-hole to handle all the DHCP business across the VLANs, which would have involved some manual editing of the DHCP server configs and binding to addresses (also a bad idea due to complexity and house-of-cards);
- Creating a process to semi-automatically "sync" DHCP assignments to the Pi-hole's
custom.list
configuration file (I was closest to actually working on this one); or - Looking into some other way to accomplish what I was doing with Pi-hole in the UniFi system.
All of these options felt too complicated and sometimes "hacky" for me, which led to...
What exactly am I trying to solve?
I recommend this moment of reflection any time a problem seems to complicated (or feels too complex). Get to the core, and for me that ended up being:
I want the Pi-hole dashboard (and data) to tell me the friendly name of devices.
The closest option in my overthought ideas was to populate the custom.list
data, but that just didn't feel right either. So a little creative The Googling later, I discovered this wonderful example of how to do this very thing.
The Ultimately "Simple" Setup
Using this guidance, I was able to easily create the reverse lookup details for the VLANs in question in /etc/dnsmasq.d/20-customdns.conf
:
server=/default/192.168.1.1
server=/mz/192.168.2.1
server=/iot/192.168.3.1
server=/guest/192.168.4.1
server=/family/192.168.5.1
server=/1.168.192.in-addr.arpa/192.168.1.1
server=/2.168.192.in-addr.arpa/192.168.2.1
server=/3.168.192.in-addr.arpa/192.168.3.1
server=/4.168.192.in-addr.arpa/192.168.4.1
server=/5.168.192.in-addr.arpa/192.168.5.1
Restarting the Pi-hole almost had immediate effect on the dashboard! Suddenly, real names started replacing the IP addresses, though it took a day or so for things to settle down fully, which is what the headline image of this post displays.
A First-World Problem
Now, this was definitely a "nice to have" thing over a requirement, but being able to see the device names properly in Pi-hole makes it significantly easier to manage stuff over there (or see if there are Problems) as necessary. An added bonus to this setup is that the individual VLAN name is also tacked on to each record's name, so it's easy to sort/identify not only the device in question, but the VLAN on which it's been talking!
I'm not truly a network dude by trade (I know things, but...), so some of this setup was heavily reliant on creative Googling. Perhaps some of this idea will work for you too!