Tech Whitepaper
How Safe Surfer deployments work
Admin architecture
Manage website classifications manually, or use any of:
- External list sync
- Our existing site classification database
- The auto-categorization system
Modifications sync immediately to the DNS for filtering.
You can combine each approach, view classification history, and view anonymous usage data.
Admin architecture (DNS servers)
DNS servers only need a database connection to function properly, so you can deploy them anywhere.
Optionally, auto-categorization can work remotely over http.
Auto-categorization architecture
Optionally, discover and classify new domains as they are visited to provide the best filtering.
Deploying this locally will get more relevant results to your particular network, but you can also rely on our upstream categorizations.
Although there's a lot going on here, the Helm chart makes this easy and flexible to set up.
Auto-categorization architecture (DNS servers)
Auto-categorization works the same way when DNS is hosted on individual servers.
The only difference is that the new domain notifier lives alongside the DNS on the server.
This keeps the complexity out of the server deployment.
Browsing history architecture
Use Clickhouse to provide speedy, ultra-scalable browsing history queries.
Altinity Clickhouse operator is automatically configured, making this super simple to set up and operate.
You can also use a managed solution like Clickhouse Cloud.
Browsing history architecture (DNS servers)
DNS servers connect to the same clickhouse instance as the rest of your deployment.
Clickhoused lives on the server and uploads history to the ingress in batches.
Per-device DNS filtering
Support per-client device filtering, per-client device browsing history, and optionally, advanced screentime features by updating or deploying routers with our router API.
No special integrations or IP linking necessary.
Gives the same functionality as our Internet Lifeguard router with a whitelabeled UI.
All features can be controlled from the same online dashboard that supports per-household and mobile device filtering.
Per-network DNS filtering
Let users block sites and categories on a per network (e.g. household) level, without replacing any existing CPEs/routers.
Just associate users with their external IP via RADIUS feed or similar, using your deployment's API.
CG-NAT support
Support per-household filtering in CG-NAT networks by adding servers inside the internal network.
Just associate users with their internal IP via RADIUS feed or similar, using your deployment's API.
Mobile devices
Optionally deploy lightweight encrypted DNS to extend protection beyond the home, or fork our open source apps to provide your own experience.
Supports DOH, DOT, DNSCrypt and plain DNS.
Easily support mobile devices running Windows 11, macOS, iOS, and Android.
Supports site blocking & browsing history for mobile devices.
Detect disconnections and notify users.
Screentime architecture
Optional. To achieve screentime features on an ISP level with good UX, we use both DNS and IP-level filtering.
Modern apps keep connections open for a long time and use DNS caching, so DNS-level screentime features take too long to take effect.
Our router API's smart firewall tracks and categorizes connections, preventing conflicts across different users, and can be remotely controlled from your central dashboard.
It discovers IPs locally, on a deployment-wide basis (static and/or dynamic), and from our central database.
Through this system, changes in screentime allowances take effect immediately from a user's perspective.
Screentime architecture (DNS servers)
Screentime works the same with separate DNS servers. The only difference is that ipsetd lives alongside the DNS on the server and uploads to the ipsetd ingress in batches.
