Every time your app connects somewhere, it first looks up the domain via DNS, and classic DNS is unencrypted, so the network can see which domains the device resolves and could tamper with the answers. Encrypted DNS, DNS over HTTPS or DNS over TLS, fixes the privacy and integrity of those lookups, and mobile platforms support it: Android's Private DNS setting and iOS's encrypted DNS configuration. It is worth understanding what encrypted DNS does for a mobile app and, just as importantly, what it does not, because it protects DNS, not your connection. Here is how encrypted DNS works on mobile and what to rely on it for.
Short answer
Encrypted DNS, DNS over HTTPS (DoH) or DNS over TLS (DoT), encrypts the DNS lookups a device makes so the network cannot easily see or tamper with which domains are resolved. Per platform support, Android offers a Private DNS (DoT) device setting and iOS supports encrypted DNS through configuration, including app-provided DNS settings. For a mobile app, encrypted DNS improves the privacy and integrity of DNS queries, hiding which domains the device resolves from network observers, but it is not a substitute for securing the connection itself: you still need TLS with proper certificate validation, which is what actually protects your traffic's content and authenticates the server. So treat encrypted DNS as DNS-level privacy, rely on TLS for connection security, and never base security decisions on DNS.
What you should know
- Classic DNS is unencrypted: the network sees which domains are resolved.
- Encrypted DNS protects lookups: DoH or DoT for privacy and integrity.
- Android has Private DNS; iOS supports encrypted DNS: at the platform level.
- It protects DNS, not your connection: TLS still secures the content.
- Do not base security on DNS: rely on TLS and certificate validation.
What does encrypted DNS do?
It protects the confidentiality and integrity of DNS lookups. The table summarizes.
| Aspect | Detail |
|---|---|
| Classic DNS | Unencrypted; queries visible and tamperable on the network |
| DNS over HTTPS / TLS | Encrypts queries between device and resolver |
| Android Private DNS | A device setting for DNS over TLS |
| iOS encrypted DNS | Supported via configuration and app-provided settings |
| What it protects | Which domains are resolved, and the answers' integrity |
DNS translates a domain name into an address, and traditionally that exchange is unencrypted, so anyone on the network path can observe which domains a device looks up, which reveals a lot about what apps and services it uses, and could tamper with the responses. Encrypted DNS wraps those lookups in an encrypted channel between the device and the DNS resolver, DNS over HTTPS or DNS over TLS, so the queries and answers are confidential and integrity-protected against the network. Mobile platforms support this: Android provides a Private DNS setting for DNS over TLS, and iOS supports encrypted DNS through configuration, including DNS settings an app or profile can provide. The protection is specifically about the DNS step, keeping the domains a device resolves private from the network and the answers trustworthy, which is a meaningful privacy improvement over cleartext DNS.
What does DNS encryption protect, and what doesn't it?
It protects the DNS lookup, not the connection that follows. This distinction is the crux. Encrypted DNS hides which domains the device resolves and protects the integrity of the answers, which is a privacy and anti-tampering benefit at the DNS layer. But once the address is resolved, the actual connection your app makes is a separate matter, and its security depends on TLS, not DNS: TLS encrypts the content of the traffic and authenticates the server through certificate validation, which is what actually protects what your app sends and confirms it is talking to the right server. So encrypted DNS does not secure your traffic's content, and it is not a defense you lean on for connection security. Notably, even DNS tampering is ultimately caught by TLS: if a spoofed DNS answer pointed your app at the wrong server, certificate validation would fail because that server could not present a valid certificate for the domain, so TLS, not DNS, is what stops you from talking to an impostor. Encrypted DNS adds query privacy on top, but the security of the connection rests on TLS.
How do you handle DNS in your app?
Rely on TLS for security, treat encrypted DNS as a privacy layer, and never trust DNS for decisions. For the security of your connections, use TLS for all communication with proper certificate validation, and certificate pinning for high-value connections, since that is what protects your traffic's content and authenticates the server regardless of DNS. Recognize that encrypted DNS is largely a device-level and network-level concern, Android's Private DNS and iOS's encrypted DNS configuration are typically set by the user or by management, so most apps benefit from it without controlling it; if your app does configure its own DNS, for example providing encrypted DNS settings, do so correctly and understand it changes query privacy, not connection security. Never make a security decision based on DNS resolution, since DNS is not an authentication mechanism, and do not assume a domain resolving means you are talking to the right server, only TLS certificate validation establishes that. Validate data server-side as always. The principle is that encrypted DNS is a worthwhile privacy and integrity improvement for the lookup step, while the security of what your app actually sends and to whom is established by TLS and certificate validation, which you must get right independent of DNS.
What to watch out for
The first trap is treating encrypted DNS as connection security, when it protects the DNS lookup, not your traffic's content; rely on TLS with certificate validation for that. The second is basing any security decision on DNS resolution, which is not authentication. The third is neglecting TLS or certificate validation on the assumption that DNS privacy covers you, when it does not. Connection security is what a scan focuses on, so a pre-submission scan such as PTKD.com (https://ptkd.com), which reads the compiled app against OWASP MASVS, surfaces whether your app uses secure transport and validates certificates, the protections that actually secure your traffic regardless of DNS, while DNS configuration is largely a platform and user concern.
What to take away
- Encrypted DNS, DNS over HTTPS or TLS, protects the privacy and integrity of DNS lookups, hiding which domains a device resolves from the network; Android offers Private DNS and iOS supports encrypted DNS.
- It protects the DNS step, not your connection: TLS with certificate validation is what encrypts your traffic's content and authenticates the server, and even catches DNS tampering.
- Rely on TLS and certificate validation for connection security, treat encrypted DNS as a privacy layer largely set at the platform level, and never base security decisions on DNS.
- Use a pre-submission scan such as PTKD.com to confirm your app uses secure transport and certificate validation, the protections that secure traffic regardless of DNS.
