DNS follows the authenticated path#
The engineering design keeps DNS in the Kurd session. The self-hosting security guide describes Unbound accepting only the TUN client pools. The app must not silently substitute a public resolver when a trusted path fails.
The engineering path is designed to keep DNS inside the tunnel.Engineering / design previewView evidence
- What this means
- DNS policy belongs to the authenticated connection, not an opportunistic public-resolver fallback.
- How the design works
- The relay implementation documents a Kurd TLS connection and TUN-scoped resolver policy.
- The limit
- The public production egress path and broad device validation are not established as released. This is not a blanket DNS-leak guarantee.
Reviewed . Source code alone is not release qualification.
Application eligibility is not a promise of connection#
The Android source model supports all-app, include-only and exclude-selected routing policies. Changing an active per-app policy requires re-establishing the interface; changing a checkbox alone is not evidence that the installed routing table changed.
An excluded application may use traffic outside the VPN unless the operating system blocks it. A route preview must distinguish VPN-eligible, direct and system-blocked outcomes rather than labelling all of them protected.
Android controls Android’s blocking policy#
Use the actual system settings to inspect platform-managed operation. A website or browser prototype cannot grant VPN permission, enable system lockdown or establish a native VPN interface.
Unqualified options do not become functional by appearing in a UI#
The app demonstration includes resolver modes, protocol choices and routing controls. A visible control is not evidence of supported production behavior; check the exact build and its documentation.
Source and scope
Reviewed . The linked source describes the implementation; released-build evidence is a separate check.