Your Network Doesn't Know Who's Home
Quick: do you know who’s home? Your spouse? Your kid? How about your toaster? Your fridge?
Do you know the last thing that connected to your network? Did you connect it?
Most people haven’t thought about it. I started thinking about it, and it turned out answering it properly was harder than I expected.
Your Network Sees Identifiers, Not Devices
Your network doesn’t know what devices are on it. It knows identifiers: long random IDs, hardware codes, names the operating system made up. Whether those belong to the same device they did last week, or the device you think they do, is a different question entirely.
People give names to things they want to recognize. We label the breaker box after the wrong circuit trips. We label the switch that gets accidentally flipped one too many times. Networks don’t do that. They assign identifiers, and those identifiers are generated by systems optimizing for their own concerns, not yours. The question isn’t whether your devices have names you’d recognize. It’s whether anyone has done the work of connecting those identifiers to something a person can actually read and act on, and whether they did it randomly or with intention.
Most people have never thought to ask what’s actually on their network. They know their phone is on it, their laptop, probably the TV. But the actual count? No idea. And that’s before you factor in the smart speaker, the thermostat, the kids’ tablets, the old phone nobody uses anymore, the streaming stick behind the TV that nobody remembers setting up.
The gap between what’s on your network and what you actually know about what’s on your network is the problem. It sounds like a nuisance. It’s actually where risk lives. An unknown device you can’t attribute is one you can’t make decisions about. Is it yours? Is it new? Has it been there for a week? You don’t know, because your network wasn’t designed to tell you. It was designed to move data.
There are solutions for every level of network complexity. Fing is a phone app that scans your network and gives you a device list. It’s quick, free, and approachable. On Android it works well. On iOS, Apple’s privacy restrictions mean it can’t see much. At the other end of the spectrum, enterprise environments run full configuration management databases (CMDBs) that track every device, its owner, its lifecycle, its software. In the middle, there are open source tools like Snipe-IT and NetBox that work well for tracking devices in smaller environments, though they’re built for IT teams and don’t solve the rotating identifier problem that drove me to build something specific.
My network has something purpose built for this. The concept was mine. I’m not a coder. The code came from a computer. But working through it gave me something I didn’t expect: a real understanding of what was being built and why. I asked the questions. I pushed back when something didn’t seem right. I wouldn’t have the registry or the web app without that collaboration.
Most people haven’t thought to ask what’s actually on their network. I started asking, and it turned out answering properly was harder than I expected.
What the Data Sources Actually See
The home SOC (a security monitoring setup that watches network activity and flags anything worth investigating) pulls from two primary data sources. NextDNS is a DNS filtering service: DNS is the system that translates website names into addresses your devices can use, and NextDNS sits in the middle of that process, logging every lookup and blocking the ones that match known threats. UniFi is the network infrastructure: the gateway, the hardware that divides the network into separate segments (VLANs), and the system that hands out IP addresses to devices when they connect (DHCP). They see very different things.
NextDNS sees DNS queries. Attached to each query is a device identifier, either a UUID (a long randomly generated ID, assigned by the device itself or by NextDNS) or a short device ID, depending on how the device connected. Sometimes a hostname, which is just a name the device reported for itself. It does not see MAC addresses. It does not see which network segment a device is on. It has no idea where on the network a device physically lives.
UniFi sees MAC addresses (a hardware identifier built into a device’s network chip, theoretically unique to that device), IP addresses, hostnames, and which network segment each device is on. It has no concept of DNS queries. It does not know what a NextDNS UUID is.
These two systems are looking at the same physical devices and sharing zero identifying keys. A UUID from NextDNS and a MAC address from UniFi can refer to the same laptop and have no fields in common. The only way to correlate them is IP-plus-timestamp: find a query in NextDNS at a specific moment from a specific IP address, cross-reference against UniFi’s address assignment records to find which device held that address at that moment. That’s a three-source manual trace, and none of it is automated.
That’s the relational problem. Multiple systems, multiple identifiers, one physical device, and no shared key between them.
The Immutable ID Problem
My first instinct was to find, or create, a stable identifier. Something that could serve as a reliable common key across all systems. A single value every source could agree on.
That instinct was reasonable. It was also wrong.
Every identifier in this stack was generated by a system optimizing for its own concerns. NextDNS UUIDs rotate. iOS cycles them on privacy updates, network changes, and sometimes for no documented reason at all. MAC addresses are authoritative on the UniFi side and invisible to NextDNS. Hostnames are set by devices that don’t know or care about your naming conventions: iphone, android-09d123uu, strings generated when the operating system hadn’t been given a real name, identical across every unconfigured device of that type on any network anywhere.
There is no cross-system identifier waiting to be discovered. Every time I looked for one, I found another rotation schedule or another system that simply didn’t speak the same language as the others.
What Actually Held: The Canonical Name
What I landed on instead wasn’t an identifier. It was a concept.
The canonical name, meaning the one agreed-upon human name for a device: “Adam’s MacBook Air,” “Ruth’s iPhone,” “School Chromebook.” That’s the stable element the registry is built around. Multiple identifiers from multiple systems all resolve to the same name. The name itself doesn’t rotate because no system touches it. It exists outside the data entirely. It’s something I decided, not something any system generated.
My MacBook Air alone has ten entries in the registry: six UUIDs from NextDNS, a short device ID, a hostname flagged explicitly as a fallback for when the UUID rotates, a Tailscale ID (Tailscale is a private networking tool that creates its own separate layer of the network, with its own identifiers), and a MAC address. None of those appear in more than one data source. But all ten resolve to the same canonical name, and the process that reads incoming data doesn’t care which one it sees. Any of them returns the right answer.
The registry currently maps 228 identifiers across 67 physical devices. That ratio, more than three identifiers per device on average, is the problem made concrete. One device, multiple ways your network might refer to it, all of them strangers to each other without the map.
The Refactor
The original registry was a simple lookup table: every identifier as an entry, canonical name as the value. Fast for the software to read, painful for a person to maintain. The question “how many physical devices are on this network?” required counting and grouping by hand. There was no obvious way to look at it and understand what you were looking at.
A few weeks in, the structure flipped. One entry per physical device. All known identifiers nested under it. Ruth’s dozen entries became one record with a dozen aliases. The software still gets the fast lookup table it needs, but it’s generated from the human-readable structure automatically, not maintained directly.
That change made the registry something a person could actually read and reason about. Which mattered, because a registry nobody wants to edit is a registry that falls behind.
The Part Where I Admit I Don’t Like Editing JSON
Maintaining the registry used to mean opening a JSON file (a structured text format that software reads easily but humans find fiddly), making changes carefully, not messing up the spacing, saving, committing to GitHub, pushing, and then remembering five minutes later that I’d forgotten something. Or getting an alert about a new device and knowing the right thing to do was go update the map but not wanting to open the file again.
So a web frontend got built to solve that. It lives on the Raspberry Pi at the heart of the network infrastructure, accessible only through Tailscale. Open it, find the device, add the alias or add the new entry, hit publish. It writes the file, generates the lookup table, commits to GitHub, and deploys out to the cloud server where Wazuh (the security monitoring software at the center of the SOC) picks it up. The whole loop that used to take ten manual steps takes one.
It does everything except the forgetting part and the making mistakes part. Those are still mine.
It’s not finished. Editing device names and a few other fields still requires going into the file directly. And honestly, it doesn’t get used as often as expected. The friction is lower, but the forgetting problem turns out to be independent of the tooling.
What I Keep Coming Back To
The registry currently covers eleven people’s devices across the household: Adam, Ruth, the kids, Terry, and a few others who show up on the network. It’s ongoing. A new device appears, I trace it, I add it. An iOS update rotates a UUID, an alert fires on an unknown identifier, I go find it and map it. The maintenance is the work.
What the registry gives back is legibility. When something unknown shows up in the security monitoring software, “unknown” actually means something. Not a known device behaving unexpectedly, but something genuinely outside the map. That’s a different kind of alert. It deserves a different kind of attention.
Devices are still a headache. They’re just a headache I know I have.
Whether the right answer was always a purpose-built solution or something that already existed, an open source inventory tool, a CMDB, something else, I’m still not sure. What I’m sure of is that the problem was real, the solution works well enough, and knowing what’s on your network is worth the effort regardless of how you get there.
At some point the registry flags something it doesn’t recognize. What happens next, the actual work of following an unknown device and finding out what it is, is a different kind of story, and it’s worth telling on its own.
ADHawk Technical Solutions — Protecting Access. Empowering People.
If you’ve ever stared at your router’s device list and wondered what half of those things are, that’s the gap. I’m glad to talk through what better visibility could look like for your environment.