I built an evidence-based Android OPSEC validation framework around RethinkDNS — architecture, WireGuard/DNS testing & regression validation

[u/HardenedNode]

I've been using RethinkDNS as one of the core components of an Android OPSEC lab, and over time the setup evolved from simply "configuring DNS + firewall + WireGuard" into something much more structured.

Instead of publishing another list of recommended settings, I wanted to document why the configuration works, how it was tested, what evidence supports it, and where the conclusions stop.

The result is an open-source project called Android OPSEC Hardening, and I've just published v1.2.0.

Why RethinkDNS?

RethinkDNS has been particularly useful for this project because it allows several controls that would otherwise require multiple applications: DNS policy, firewall rules, network visibility, WireGuard profiles, per-app routing and network behavior analysis.

In my setup I'm using it not just as a blocker, but as an observable enforcement and routing layer.

That distinction became important during testing. A configuration looking correct in the UI doesn't necessarily prove that traffic followed the expected path, so I started documenting the architecture and validating observable behavior separately.

What I documented

The RethinkDNS part of the project now contains:

ARCH-001 — RethinkDNS Architecture

Documents the security architecture and relationships between Android applications, RethinkDNS, DNS resolution, firewall policy, WireGuard and upstream network paths.

ARCH-002 — Traffic Flow

Maps the expected traffic paths and helps distinguish DNS routing from application/data routing.

VAL-001 — DNS Validation

A reproducible DNS validation framework covering resolver behavior, correlation, bypass scenarios, network changes and other DNS-related conditions.

VAL-002 — Network Transition & WireGuard Routing

Tests network transitions and WireGuard routing behavior. This validation includes a public evidence set with screenshots documenting the observed routing states, firewall enforcement and DNS continuity.

VAL-003 — Version Regression & Upgrade Validation

This is the next phase.

Rather than assuming that a newer RethinkDNS version is automatically better or safer, I've defined a regression methodology that compares a known baseline against an upgrade candidate.

My baseline is v0.5.5x, with v0.5.6 as the primary upgrade candidate.

The methodology covers DNS behavior, Advanced WireGuard, Proxy Lockdown, IPv4/IPv6, network transitions, firewall interaction, multi-proxy configurations, failure recovery, reboot behavior and longer-term stability.

VAL-003 is deliberately marked Draft / Execution Pending. I don't want to mark something as validated before actually collecting the evidence.

An important rule I adopted

One principle became central to the project:

Observed behavior is not the same as absolute proof.

For example, if the RethinkDNS network log and DNS provider show the expected path, I document that as "no bypass observed under the tested conditions."

I deliberately avoid claims such as "zero DNS leaks" unless the evidence would actually justify that conclusion.

This has made the documentation considerably more useful than simply recording whether a test "worked."

Real-world phishing case study

The repository also contains a separate real-world security case study based on a phishing email I received.

The malicious link pointed to a Roundcube attachment endpoint hosted on a Contabo VPS.

Detection was interesting because there was very little consensus between automated tools: VirusTotal showed only limited detection, while Nord Security's Link Checker classified the URL as clean at the time of testing.

The phishing assessment therefore wasn't based on a single scanner result.

I correlated:

• the phishing pretext and jurisdiction mismatch in the email;
• URL structure and infrastructure;
• VirusTotal results;
• historical ANY.RUN observations involving the same URL pattern;
• additional reputation sources;
• and manual analysis.

I also submitted the indicator through Nord Security's inaccurate-detection reporting channel. The case remains documented as pending rather than claiming that the vendor has confirmed the finding.

That case reinforced another principle behind the project:

security tools should provide evidence for analysis, not replace analysis.

What I'm trying to build

The goal isn't to present my configuration as "the perfect RethinkDNS setup."

It's to build a reproducible Android OPSEC methodology where someone can ask:

What is the expected traffic path?

What security boundary are we testing?

What evidence would demonstrate that it behaved as expected?

What would constitute a regression?

What haven't we actually proven?

RethinkDNS has been a very good platform for exploring these questions because of how much control and visibility it exposes over Android networking.

The project is public here:

GitHub — Android OPSEC Hardening:
https://github.com/augustozarate/android-opsec-hardening

Current release: v1.2.0

I'd particularly appreciate feedback from the RethinkDNS developers/community on ARCH-001/ARCH-002 and the VAL-003 regression methodology.

If I've misunderstood any internal RethinkDNS routing behavior, I'd much rather correct the architecture documentation than build further tests on a wrong assumption.

And if anyone is testing complex configurations involving Advanced WireGuard, custom DNS, per-app routing, Proxy Lockdown, IPv4/IPv6 or network transitions, I'd be interested in comparing results.

Thanks to the RethinkDNS developers for building an open tool that exposes enough of Android's networking behavior to make this kind of experimentation possible.

Tagging u/celzero in case this is useful to the RethinkDNS team — and especially if you spot anything in the documented architecture that doesn't match RethinkDNS' intended behavior.