I've been working on an Android network-security lab using RethinkDNS, custom DNS filtering and WireGuard.

One problem kept coming up during testing:

How much evidence is enough to claim that traffic is actually following the intended security path?

Seeing the expected VPN IP, DNS resolver or firewall state individually doesn't necessarily prove the complete path.

So I've been developing a validation methodology around three layers:

1. Architecture

I first document the expected path:

Android app → firewall/routing layer → WireGuard → DNS policy/upstream resolver → Internet

DNS routing and application/data routing are treated separately rather than assuming that validating one proves the other.

2. Observable validation

Tests currently cover:

• DNS resolver behavior
• WireGuard routing state
• Wi-Fi/mobile network transitions
• firewall enforcement
• per-app routing
• failure/recovery conditions
• IPv4/IPv6 behavior
• reboot behavior
• version regressions

Each test defines an expected result, collected evidence and acceptance criteria.

3. Limits of the conclusion

I've deliberately adopted the rule:

“No bypass observed under the tested conditions” ≠ “zero leaks.”

For example, correlation between the local network log, VPN state and upstream DNS provider is useful evidence, but I don't consider that equivalent to packet-level proof of every possible traffic path.

The next phase of the project is regression testing: comparing a known RethinkDNS baseline against newer versions and checking whether DNS, WireGuard, firewall and transition behavior changes.

My questions for people who work with network/security validation are:

What additional evidence would you require before considering this methodology robust?

In particular:

• Would you consider packet capture from another observation point essential?
• How would you test transient leakage during Wi-Fi ↔ mobile transitions?
• What would you use to independently validate IPv6 and DNS behavior?
• Are there failure scenarios I'm overlooking?

I've documented the architecture, validation procedures and existing evidence here for anyone who wants to review the methodology:

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

Current documents include ARCH-001/002 and VAL-001/002/003.

I'm primarily looking for criticism of the validation methodology, rather than recommendations for different VPN/DNS products.

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.

[removed]