One Month of Pi-hole: What My Network Was Quietly Calling Home To

Every device on a network is talking, all the time. Phones check for updates. Smart TVs report what's being watched. Apps send analytics. Browsers fetch ads and tracking scripts from dozens of domains on a single page. Most of this traffic is invisible to the people who own the devices.

Running Pi-hole as the DNS server for my home network made that traffic visible. After a month of studying its dashboard and query logs, I had a far clearer picture of what "normal" looks like on a network, and a much better understanding of how DNS can be used for both privacy and security monitoring.

This article shares what I saw and what it taught me. A note before I start: I'm describing patterns rather than publishing my own logs, because DNS logs reveal a lot about the people using a network. That's a lesson in itself.

A quick recap: what Pi-hole does

Pi-hole is a DNS server that blocks requests for domains on blocklists, typically lists of known advertising, tracking and malicious domains. In my home lab, it runs in a Docker container on an Ubuntu server. My router hands out Pi-hole's address as the DNS server, so every device on the network uses it automatically.

When a device asks for a domain on a blocklist, Pi-hole answers with nothing, so the connection never happens. Allowed requests are forwarded to an upstream DNS resolver. Every query, allowed or blocked, is logged.

Observation 1: the volume is surprising

The first thing that stands out on the dashboard is the sheer number of queries. Even with only a few people at home, the network makes thousands of DNS requests a day.

Much of that volume happens when nobody is actively using anything. Overnight, phones on chargers, smart TVs on standby and laptops asleep but still connected keep making requests. Devices are rarely truly idle.

What it teaches: if you're going to monitor a network, you need a baseline. Without knowing what normal background traffic looks like, you can't recognize what's abnormal.

Observation 2: a large share of requests are tracking and telemetry

A meaningful portion of queries go to advertising, analytics and telemetry domains. Some come from websites, but many come from apps and devices directly: usage statistics, crash reports, advertising identifiers and "phone home" checks.

Not all telemetry is bad. Crash reports and update checks are useful. But the sheer number of different third-party domains contacted by ordinary apps is striking.

What it teaches: data leaves devices constantly, often to parties the user never chose to share it with. In a business, this matters for privacy compliance and for understanding where company data might be going.

Observation 3: smart devices are the chattiest

The devices that generated the most queries weren't the computers. They were the "smart" devices, such as TVs and streaming boxes, which contacted large numbers of domains repeatedly, often around the clock.

These devices are also the hardest to control. You can't install security software on most of them, and their settings rarely offer much privacy control. DNS filtering is one of the few tools that works for them.

What it teaches: in organizations, the equivalent devices, such as printers, cameras, building systems, conference room displays and production equipment, are often the least visible and least managed. They deserve their own network segment and monitoring.

Observation 4: patterns reveal behaviour

DNS logs show when devices are used and what services they reach. Looking at the timeline, you could infer when people wake up, which apps they use and when they're home.

That's exactly why I'm not sharing my own logs, and why DNS logs in organizations must be handled carefully. They're valuable for security, but they're also sensitive personal data.

What it teaches: monitoring and privacy have to be balanced. Organizations that log DNS should have clear policies on who can access the logs, how long they're kept and what they're used for.

Observation 5: blocking has side effects

Occasionally, something broke. A website wouldn't load properly, a streaming app failed or a shopping link didn't redirect. Usually the cause was a blocked domain the service depended on, often a tracking or redirect domain built into the normal flow.

The fix was straightforward: find the blocked domain in the query log around the time of the failure and add it to the allow list. But it reinforced an important point: every security control has a cost in usability.

What it teaches: at work, DNS filtering and other blocking controls need a fast, clear way for users to report problems and for IT to make exceptions. Otherwise, people find workarounds that bypass the control entirely.

Observation 6: devices sometimes ignore your DNS

Some devices and apps are configured to use their own DNS servers or encrypted DNS (such as DNS over HTTPS), bypassing the network's DNS server entirely. Their queries simply don't appear in Pi-hole's logs.

What it teaches: DNS monitoring has blind spots. Organizations that rely on DNS filtering often also block outbound DNS to unauthorized servers at the firewall and manage encrypted DNS settings on company devices. Knowing what your controls can't see is as important as knowing what they can.

Questions I now ask about any device

After a month of watching the logs, I started asking the same set of questions about every new device that joined my network. They work just as well for evaluating equipment at work.

• Who does it talk to? List the domains it contacts in its first day. Are they the manufacturer, a cloud service you recognize, or a long tail of third parties?
• How often? Constant check-ins every few seconds suggest heavy telemetry. Occasional requests suggest a quieter device.
• What happens when you block telemetry? Some devices keep working perfectly. Others stop working, which tells you how dependent they are on the vendor's cloud.
• Does it respect the network's DNS? If its queries never appear, it may be using its own DNS servers or encrypted DNS.
• Does it get updates? Seeing regular requests to an update service is a good sign. A device that never checks for updates may never be patched.
• Does it need to be on the main network at all? Many smart devices can live on a separate guest or IoT network with no access to computers and file shares.

These questions turn a vague feeling of "smart devices are risky" into specific facts you can act on, at home or in a business deciding whether to approve a new device.

How this connects to security work

DNS is one of the most useful data sources in a security operations centre, because almost every connection starts with a lookup. The patterns I watched on a small scale at home are exactly what analysts look for at work:

• Known malicious domains. Threat intelligence feeds list domains used for malware, phishing and command-and-control. A query to one of them is a strong signal worth investigating.
• Newly registered or look-alike domains. Phishing campaigns often use domains created days earlier, or names that imitate trusted brands.
• Unusual volumes or timing. A workstation making thousands of queries at 3 a.m. deserves a closer look.
• Strange-looking names. Long, random-looking subdomains can indicate malware generating domains automatically, or data being smuggled out inside DNS queries, a technique known as DNS tunnelling.
• Beaconing. Requests to the same domain at very regular intervals can indicate malware checking in with its controller.

Running Pi-hole won't make you a threat hunter, but it trains your eye. Once you've studied normal traffic for a month, unusual patterns stand out much more clearly.

Tips if you want to try this

• Start with default blocklists. Adding too many lists at once causes more breakage and makes troubleshooting harder.
• Point one device at Pi-hole first, then the whole network once you're comfortable.
• Plan for downtime. If Pi-hole goes down, name resolution fails for everything. Consider a secondary DNS option or keep the server reliable.
• Respect privacy. If others share your network, let them know DNS is logged, and limit how long you keep logs.
• Use it to learn. Pick a device, watch its queries for a day and try to explain each domain it contacts.

The takeaway

A month of Pi-hole showed me that networks are far busier than they look, that ordinary devices share a lot of data, and that DNS is one of the clearest windows into what's happening on a network. Those lessons apply directly to security monitoring at any scale.

If you ran DNS filtering on your network for a month, which device do you think would be the chattiest?