Skip to content

Content Filter and DNS

yybam edited this page Oct 7, 2026 · 1 revision

Content Filter and DNS

CORE MDM offers two network-control features in the Network tab: a DNS content filter (a local VPN) and Private DNS enforcement. Both need Device Owner.

Content filter (DNS VPN)

DnsVpnService runs a local VpnService that routes DNS traffic only (it adds a route for the fake DNS address, not all traffic) so it can inspect/filter name lookups against a blocklist.

The consent problem — and the fix

Android requires a one-time on-device consent tap before any app can start a VPN. The web console can't trigger that tap, so before v0.4.1 the toggle silently failed (establish() returned null → "Failed to establish VPN tunnel").

From v0.4.1, on a Device Owner device the app registers itself as the always-on VPN (setAlwaysOnVpnPackage). That pre-authorizes the tunnel and starts it — so the Enable Content Filter toggle just works, with no on-device step, and it survives reboot. On non-Device-Owner devices the app falls back to starting the service directly, which still needs the manual consent tap.

Using it

Network tab → Enable Content Filter. When on, you'll see a persistent "CORE MDM Filter" VPN notification and a tun0 interface on the device. Toggling off clears the always-on registration and tears down the tunnel.

Blocklists

Blocklist parsing supports hosts-format lists (BlocklistParser / BlocklistRepository); imports are kept separate from any custom list.

Private DNS

Network tab → enter a DNS hostname (e.g. dns.cloudflare.com) and Lock DNS. The device sets the global Private DNS mode to hostname with your specifier and, on Android 10+, blocks the user from changing it (DISALLOW_CONFIG_PRIVATE_DNS). Clear reverts to opportunistic mode and unlocks it.

privateDnsHost is stored in the policy map; empty string clears it.

Content filter vs Private DNS

Content filter VPN Private DNS
Mechanism Local VpnService routing DNS System DNS-over-TLS to a host
Filters by Blocklist in the app Whatever the DNS provider enforces
Needs consent/always-on Yes (auto on DO) No
Good for Custom blocking on-device Enforcing a filtering resolver

You can use either or both.

Related

Clone this wiki locally