DNS is the naming layer of the internet. Blocking at that layer can stop a device from discovering where a service lives. It does not inspect the service’s content, erase existing connections, or turn a general-purpose phone into a sealed appliance.
DNS in one minute.
Apps usually connect to names such as api.example.com, not to a
memorized server address. DNS converts that name into information the device
can use to make a connection. The core protocol is defined by the IETF, and the
answer can be cached for a period chosen by the DNS record.
A DNS blocker changes the middle step. When a requested name matches a rule, it returns a blocking result instead of a usable destination. When it does not match, the lookup continues to the configured DNS resolver.
Where filtering happens on iPhone.
Apple’s Network Extension framework lets an app provide network and DNS configuration through an extension. LetMeBe uses the on-device profile iOS requires, checks selected app and host rules locally, and forwards allowed DNS queries to the resolver you choose.
That system profile can make iOS show a VPN indicator. The label describes an operating-system interface, not a promise of anonymity. LetMeBe does not operate a remote full-traffic VPN tunnel and does not read message or page contents.
The layer is the product. LetMeBe is designed to decide whether a DNS name should resolve. It is not trying to decrypt or proxy the connection that follows.
What DNS blocking can do well.
- Stop new lookups for known service domains. This can make a selected app unable to refresh or complete network actions.
- Leave unrelated apps online when their dependencies do not overlap. Rules apply only to the app definitions and custom hosts you enable, but a shared host can still affect more than one app.
- Work across Wi‑Fi and mobile data. The filtering profile follows the device rather than a single Wi‑Fi router.
- Express understandable policy. A hostname is easier to review and remove than a rotating collection of server addresses.
- Keep payloads out of scope. A DNS decision needs the name and answer, not the message, image, or page content carried later.
What it cannot honestly promise.
DNS filtering does not hide your IP address from destinations, encrypt all traffic, detect malware inside downloads, control what happens on another device, or guarantee that every feature of an app is offline.
It also cannot distinguish two apps when both legitimately depend on the same shared host. Blocking that host may affect both. LetMeBe marks known shared and system infrastructure as unsafe instead of encouraging an aggressive rule.
A claim such as “completely block any app” is too broad for DNS. The honest claim is narrower: block matching new DNS lookups for the rules the user selects.
Why a correct rule can appear to miss.
The connection already exists
Once an app has an open connection, it may keep using it without asking DNS again. Close and reopen the app after changing a rule.
The answer is cached
DNS answers are deliberately reusable. Until a cached answer expires, the app or operating system may not perform another lookup.
The app uses another name
Modern apps divide work across APIs, media hosts, authentication services, analytics endpoints, and CDNs. One hostname may block one feature while another feature continues.
The app connects by address
A direct IP connection does not need a DNS question. LetMeBe keeps legacy IP entries inactive because global IP routes cannot safely isolate selected apps.
Apple delivers a notification
Remote notifications can travel through Apple Push Notification service even while the app’s normal service domains are blocked.
What DNS over HTTPS changes.
DNS over HTTPS, standardized as RFC 8484, places each DNS query and response in an HTTPS exchange. That protects the lookup from casual observation or modification between the client and the chosen resolver.
DoH does not make DNS anonymous. The resolver still receives the query, and the destination still sees the later connection. LetMeBe lets you choose a preset or custom DoH resolver; that choice determines who handles allowed lookups after the on-device rule check.
How to evaluate a DNS filter.
- Demand a precise scope. Does the product say DNS filtering, full-tunnel VPN, content filter, or firewall? Those are not synonyms.
- Look for failure disclosures. Existing sessions, caches, direct IP traffic, shared hosts, and APNs should not be hidden in fine print.
- Test one observable action. Trigger fresh content in the target app, then verify an unrelated app still works.
- Prefer reversible rules. Add one host, test, and remove it immediately if collateral effects appear.
- Know where processing occurs. Read the privacy notice for identifiers, DNS evidence, recipients, and retention—not just a “private” badge.