SnitchScan audits a home network's DNS logs every morning

phlux404 kept catching apps on his network phoning home to trackers. One app sold as a privacy tool, he says, was quietly calling Google’s Firebase the whole time. Checking DNS logs by hand was eating hours, so he and his Muse agent, Quill, built an auditor over a few evenings. He calls it SnitchScan, and it now reads his network’s DNS history every morning before he does.

The interesting part is not that it flags trackers. Plenty of blocklists do that. It is the division of labor: the scan runs on its own, the agent does the research on anything new, and the human makes every block-or-keep call.

How it works

A script on a Debian box pulls the previous day’s logs from NextDNS, the DNS service phlux404 already used. It checks every domain against a curated tracker database and two detectors. The first is a Shannon-entropy check that looks for random-looking subdomains, a common pattern for tracking endpoints; phlux404 calibrated it at about a 3% false-positive rate. The second fingerprints domain patterns that belong to known SDKs.

The output is a plain report written into his own Nextcloud Notes. To get a phone alert without going through Google’s push service, the pair built a second small tool, ncnotify. “I read it with my coffee,” he wrote.

The schedule is fixed: the box pulls logs at 6am and the report is waiting before he is awake. The verdicts are deliberately not automated. When something unknown gets flagged, Quill investigates it (what the endpoint is, who runs it, what data it carries, and what his DNS is currently doing with it) and brings back a recommendation. phlux404 decides. Quill then does the bookkeeping, updating the database everywhere it lives and writing a dated verdict file into the repo, starting with VERDICTS-2026-10-13.md. Each file records what was flagged, why, and what was decided, so a call can be revisited if an endpoint changes behavior.

“I wouldn’t automate the decision itself, the human verdict is the product,” he wrote.

Everything is Python using only the standard library, plus the NextDNS API. The log analyzer also runs as a fully offline web page: paste a log in and nothing leaves the browser. The project is published under GPL-3.0 as phlux404/snitchlist, and he puts the extra cost at $0, since he already had the hardware and the DNS service.

What it caught

The week he posted, the report flagged firebaselogging-pa.googleapis.com, Firebase’s logging pipe, which is now blocked and classified. It also flagged shortwave.facebook.com, which turned out to be his own traffic: Meta’s speech-services endpoint, used when he dictates messages to Quill in the Muse app. It was filed as known infrastructure. “The machine files its own false alarms now,” he wrote.

He is open about the limits. The database is curated rather than complete, the entropy detector does produce false positives (which is why the verdict step exists), and the automated pipeline only understands NextDNS logs.

What the server said

N8, one of the server’s admins, read the repo and called remembering verdicts “especially useful.” He pointed out that the 3% figure came from 33 benign domains and wondered how it would hold up on other people’s logs. He also asked whether Quill blocks domains on its own and how phlux404 traced the Facebook endpoint to dictation.

phlux404 agreed the false-positive question is open. “Benign” is household-specific: the dictation endpoint only shows up for people who use Muse’s built-in speech-to-text. That is part of why the offline analyzer exists, so anyone can build their own false-positive set. On the dictation question he admitted there had been no controlled test at first; the name looked random, it was flagged on entropy alone, and the volume matched how much he dictates. Then he tested it. Blocking the endpoint broke Muse’s dictation, and unblocking it brought dictation back after a phone restart.

N8 later asked whether he had tried having Quill talk to other members’ Muse agents. He had not.