Aunt Cass Internet History

Understanding the Aunt Cass Internet History Approach

Aunt Cass Internet History is a method some people use for tracking and categorizing browsing data on home networks, mostly by parents or small-office administrators who need visibility into what devices are pulling up. The concept is straightforward enough — you set up a DNS-level or proxy-level log that records URLs visited across connected devices, and you filter or flag things based on a ruleset. I started using something like this about four years ago after my kids were spending unreasonably long stretches on YouTube and something felt off about the algorithms pushing them toward stranger corners of the internet. I went with a Pi-hole setup first, then moved to a custom Squid proxy on a Raspberry Pi 4 with a SQLite backend. The Pi-hole gave me query logs, but it didn't give me categorized results or time-based reporting. That's where the "Aunt Cass" part comes in — a lightweight Python script that reads the raw DNS logs, matches URLs against a curated blocklist, and spits out a CSV report I can review on Sunday nights. The script itself isn't anything fancy. It polls the dnsmasq cache every five minutes, matches entries against a keyword-and-whitelist system, and writes to a local database. One thing beginners miss: DNS logging alone won't catch HTTPS traffic on encrypted domains because the SNI (Server Name Indication) in the TLS handshake is what's actually logged, not the full URL path. So you'll see "youtube.com" show up, but not the specific video. That's a real limitation if you're trying to monitor what's actually being consumed. The workaround is running a transparent proxy on port 8080 with SSL bumping enabled, which does decrypt and log the full paths — but that breaks on any site with strict HSTS and requires you to install a custom root CA on every device. I've seen people spend three days fighting certificate errors before realizing they'd rather just accept partial visibility.

Another thing nobody warns you about: DNS rebinding attacks and local network abuse. A kid who figures out how to change their device's DNS to 8.8.8.8 bypasses the whole system. I had that happen within two weeks of deployment. The fix is setting static DHCP reservations tied to MAC addresses and forcing the router to push the Pi-hole IP as the only DNS option via DHCP option 006. Some routers let you do this natively. Cheap ones don't, and you end up reflashing with OpenWrt. The blocklist I use is a combination of the standard NoTrack list and a custom additions file I've built up over time. I avoid the biggest commercial blocklists because they tend to false-flag educational content and medical information sites. One specific edge case: my daughter needed access to a mental health resource site that was categorized as "adult" by a major blocklist. I spent a morning whitelisting it by category rather than by individual domain, which is the better long-term approach. Whitelist by category, blocklist by domain — that's the rule I follow now. If you want something more turnkey, there are a few existing projects on GitHub that implement this pattern without requiring you to write your own scripts. One popular repo bundles the Python logger, a web dashboard, and pre-built blocklists. It runs on Docker and takes about twenty minutes to deploy if your network setup is normal. The trade-off is less customization and a dependency on someone else's update schedule.

The honest downsides: this system eats about 200MB of disk per month on a five-person household, requires constant list maintenance to stay accurate, and will never be 100% effective against deliberately obfuscated traffic. If you're looking for complete visibility, you need full packet inspection tools like Zeek or a commercial product, and those are overkill for most home use. The Aunt Cass approach sits somewhere between "do nothing" and "surveillance state," which is probably why people keep reinventing it in different forms. Start with DNS logging, see what gaps bother you, then layer in a proxy if you actually need the extra detail. Don't jump straight to the complex setup — you'll burn out on maintenance before you get through a week of useful data.