Ordinary DNS lookups travel unencrypted, so anyone on the path, from a café Wi-Fi operator to a compromised home router, can read every site name a device looks up and can answer with a false address. Private DNS (Android's name for encrypted DNS) and the equivalent settings on iPhone, Windows, browsers and routers fix the transport by wrapping DNS in TLS, HTTPS or QUIC. They do not make the resolver itself trustworthy, so choosing the resolver matters as much as switching encryption on. This guide explains what each protocol does, how to turn encrypted DNS on for each platform, how strict and opportunistic modes behave, how to choose a resolver, and how to make it work alongside a home router, parental controls and VPNs. It is for security-minded individuals, people who look after a family's devices, and IT staff supporting home workers. For managed corporate fleets, see the Encrypted DNS Enterprise Guide.
Key takeaways
- Encryption protects the path, not the destination. Encrypted DNS stops the local network and its operator reading or altering lookups, but the resolver you choose still sees every query.
- Android has a built-in switch. Private DNS uses DNS over TLS; Automatic mode upgrades opportunistically, and entering a provider hostname forces all lookups to that resolver with no fallback.
- iPhone needs a profile or an app. iOS and iPadOS 14 and later support encrypted DNS through a DNS Settings configuration profile or a DNS app, not a toggle in Settings.
- Strict beats opportunistic. Opportunistic modes silently fall back to clear text; strict modes fail closed, which is safer but needs a reachable resolver.
- Pick a resolver by its policy. Check log retention, whether it filters and discloses its block lists, DNSSEC validation and its transparency reporting before trusting it with your browsing history.
What encrypted DNS is and what it protects
Classic DNS uses UDP and TCP on port 53 in clear text. Three IETF standards encrypt the connection between a device and its recursive resolver:
| Protocol | Standard | Transport and port | Where you meet it |
|---|---|---|---|
| DNS over TLS (DoT) | RFC 7858 (May 2016), usage profiles in RFC 8310 (March 2018) | TCP port 853; must not use port 53 | Android Private DNS, routers, iOS profiles |
| DNS over HTTPS (DoH) | RFC 8484 (October 2018) | HTTPS, default port 443, configured with a URI template | Browsers, Windows, iOS profiles |
| DNS over QUIC (DoQ) | RFC 9250 (May 2022) | UDP port 853; must not use UDP port 53 | Some resolvers and apps |
- What it stops: passive reading of lookups by the Wi-Fi operator or anyone on the path, and on-path tampering with answers, an adversary-in-the-middle technique (ATT&CK T1557).
- What it does not stop: the resolver operator seeing your queries; the destination IP address being visible on the network; tracking by websites; malware that uses its own DNS. Google's Android announcement makes the same point: DNS over TLS covers DNS only, not other privacy risks.
- Who still sees your lookups: whichever resolver you choose. Switching from your internet provider to a public resolver moves trust; it does not remove it.
Strict and opportunistic modes
RFC 8310 defines two profiles that explain most of the confusing behaviour on real devices.
| Profile | Behaviour | Device examples | Risk |
|---|---|---|---|
| Opportunistic Privacy | Uses encryption and authentication when available; may fall back to unauthenticated or clear-text DNS to get an answer | Android Private DNS Automatic; Chrome secure DNS automatic mode; Windows "Encrypted preferred, unencrypted allowed" | Silent downgrade by a hostile network |
| Strict Privacy | Requires an encrypted, authenticated connection; hard failure otherwise, no clear-text fallback | Android Private DNS with a provider hostname; Chrome with a custom provider; Windows "Encrypted only" | Name resolution fails if the resolver is blocked or unreachable |
For phones that move between untrusted networks, strict mode is the better default. When a network blocks it, the device shows no connectivity rather than quietly leaking lookups; Google's Android announcement notes the network is marked "No internet access" if the chosen server cannot be reached.
Turning it on: platform by platform
| Platform | Where the setting is | Protocol | Notes |
|---|---|---|---|
| Android 9 and later | Settings, search for "Private DNS" (under Network and internet on most devices); choose Off, Automatic or Private DNS provider hostname | DoT | Enter a hostname, not an IP address. Applies to system DNS for all apps using system APIs. An active VPN uses its own DNS instead |
| Chrome on Android | Settings, Privacy and security, Use secure DNS | DoH | On in automatic mode by default with fallback; a custom provider does not fall back. Unavailable when the device is managed or parental controls are on |
| iPhone and iPad (iOS/iPadOS 14+) | Install a DNS Settings profile (payload type com.apple.dnsSettings.managed) or a resolver's app; then Settings, General, VPN and Device Management | DoH or DoT | A manually installed profile also applies on cellular; one delivered by MDM applies only to managed Wi-Fi networks |
| iPhone with iCloud+ | iCloud Private Relay | Apple relay design | Encrypts DNS records for Safari browsing so neither the network provider nor the first relay sees the site name; not available in all regions |
| Windows 11 and Windows Server 2022+ | Settings, Network and Internet, adapter, DNS server assignment, Edit; set Manual and choose the DNS encryption option | DoH | Encryption is offered for resolvers on the known DoH server list; "Encrypted preferred" falls back without notification |
| Firefox | Settings, Privacy and Security, DNS over HTTPS | DoH | In default mode Firefox disables DoH on networks that signal filtering through a canary domain or show parental controls; a manually chosen "always" setting ignores the signal |
| Home router | Router admin page, WAN or DNS settings, if the firmware supports DoT or DoH forwarding | DoT or DoH upstream | Protects lookups from the router to the resolver only; the hop from each device to the router stays clear text on your own Wi-Fi |
On Windows the default known DoH server list (visible with Get-DnsClientDohServerAddress) includes 1.1.1.1 and 1.0.0.1, 8.8.8.8 and 8.8.4.4, and 9.9.9.9 and 149.112.112.112 with their IPv6 equivalents. Other resolvers can be added with Add-DnsClientDohServerAddress, setting -AllowFallbackToUdp $False for strict behaviour. Microsoft advises against requiring DoH on domain-joined machines because the Windows Server DNS service does not answer DoH and Active Directory depends on DNS.
See the Android Security and Privacy Settings Guide and the iPhone Security and Privacy Settings Guide for the rest of each platform's settings.
Choosing a resolver
Mozilla's Trusted Recursive Resolver policy is a useful public yardstick, because it sets written requirements that resolvers must meet before Firefox will offer them. Use it as a checklist for any provider, whether or not Firefox lists it.
| Criterion | What good looks like | Where to check |
|---|---|---|
| Log retention | User-identifying data kept only to operate the service and for no longer than 24 hours (the Mozilla requirement); longer retention only for aggregate data | Provider privacy notice |
| Data sharing | No selling, licensing or transfer of IP addresses, identifiers or query patterns to third parties except as required by law | Privacy notice and terms |
| Filtering | Clear statement of whether the resolver blocks domains, with documented block lists; nonexistent domains answered with an accurate NXDOMAIN, not redirected | Provider documentation; choose a filtering or unfiltered endpoint deliberately |
| Transparency | Annual transparency report on law enforcement requests | Provider website |
| EDNS Client Subnet | Not sent to authoritative servers over unencrypted connections (Mozilla requirement); ideally not sent at all for privacy | Provider documentation |
| DNSSEC validation | The resolver validates signed zones and refuses forged answers | Provider documentation; see the DNSSEC Deployment Guide |
| Protocols and reach | DoT hostname for Android, DoH template for browsers and Windows, both reachable from networks you use | Provider setup pages |
- Privacy first: choose an unfiltered endpoint with short retention and a published transparency report.
- Protection first: choose a resolver endpoint that blocks known malicious domains, which is the consumer equivalent of protective DNS. See the Protective DNS Guide.
- Family devices: a family-filtering endpoint set as the Private DNS hostname gives filtering that follows the phone onto mobile data, which router-level filtering cannot. See the Parental Controls Guide.
- Work devices: do not override the employer's resolver on a managed device; it may break internal names and will bypass security filtering.
Home networks: router, devices or both
A home network has two hops: device to router, and router to resolver. Router-level encrypted DNS protects the second hop for every device, including smart TVs and consoles that have no setting of their own. Device-level Private DNS protects both hops but only for that device, and it travels with phones onto other networks.
- Do both where you can: configure the router to forward over DoT or DoH, and set Private DNS on phones and laptops that leave the house.
- Expect devices to bypass the router: browsers with DoH and phones with Private DNS no longer use the router's resolver, so router-based filtering and logging only see what remains. Firefox looks for a canary domain signal on the network before enabling DoH in default mode.
- Automatic upgrade from a known resolver: RFC 9462 Discovery of Designated Resolvers (November 2023) lets a client that knows only the resolver's IP query
_dns.resolver.arpato find its encrypted endpoint, and use it automatically only if the resolver's certificate contains the original IP address. For private addresses such as a home router, clients may use opportunistic discovery without that check. - A secure router still matters: an attacker who changes the router's DNS settings controls every device that relies on it. See the Securing Your Home Router Guide and the DNS Hijack Playbook.
How to implement
- Choose the resolver and endpoint using the criteria table, and note both its DoT hostname and its DoH URL.
- Start with one phone. On Android set Private DNS to the provider hostname; on iPhone install the provider's signed profile or app. Use the provider's test page, where offered, to confirm queries arrive encrypted.
- Test the edge cases: a hotel or café captive portal, your VPN, and any work app that resolves internal names. Captive portals may need Private DNS turned off briefly to sign in; turn it back on afterwards.
- Configure laptops and browsers. Prefer the operating system setting over per-browser settings so every application is covered, and choose the encrypted-only option where offered.
- Configure the router to forward upstream over DoT or DoH if its firmware supports it, and update the firmware first.
- Roll back cleanly if something breaks: set Android Private DNS to Automatic, remove the iOS profile under VPN and Device Management, or switch Windows back to Automatic (DHCP) DNS.
- Review twice a year: check the resolver's privacy notice for changes and confirm settings survived operating system updates.
Checking it works and measuring it
- Provider test pages: many resolvers publish a page that reports whether your query reached them and over which protocol.
- Router or firewall logs: if you run your own firewall, outbound UDP or TCP port 53 from a device that should be using Private DNS shows a fallback or an app with its own resolver; TCP port 853 shows DoT in use.
- Windows:
Get-DnsClientDohServerAddresslists DoH templates and whether fallback to UDP is allowed. - Android apps: apps that run their own DNS can check
LinkProperties.isPrivateDnsActive(), per Google's guidance; those that ignore it can leak.
Useful measures for a household or a small team supporting home workers:
- Share of devices with encrypted DNS in strict mode.
- Share of devices whose resolver meets every criterion in the table.
- Number of devices still sending clear-text port 53 traffic off the network.
- Router firmware age and whether its DNS settings match the intended values at each check.
Common failure patterns
- Leaving Automatic mode on and assuming protection. Opportunistic modes fall back to clear text without telling you.
- Typing an IP address into Android Private DNS. The field needs a hostname so the certificate can be validated.
- Expecting a VPN and Private DNS to stack. When a VPN is active its DNS settings apply, as Quad9's Android setup guide notes; configure the resolver inside the VPN app instead.
- Choosing a resolver by speed alone. The fastest resolver may log more and keep it longer.
- Breaking parental controls by accident. Device or browser DoH bypasses router filtering; set the family filtering endpoint on the device itself.
- Overriding DNS on a work device. This breaks internal names and protective DNS, and may break policy.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.DS-02 | Protecting data in transit, including name resolution traffic |
| NIST SP 800-53 Rev. 5 | SC-8, SC-21 | Transmission confidentiality and integrity; secure recursive or caching resolution |
| CIS Controls v8.1 | Control 9 (Email and Web Browser Protections) | Use of DNS filtering services |
| MITRE ATT&CK | T1557 | Adversary-in-the-middle tampering that encrypted DNS helps prevent |
Practitioner checklist
- Choose a resolver against the retention, sharing, filtering, transparency and DNSSEC criteria.
- Set Android Private DNS to the provider hostname, not Automatic.
- Install a signed DNS Settings profile or the resolver's app on iPhones and iPads.
- Use the operating system's encrypted-only option on laptops.
- Configure the router for encrypted upstream DNS and keep its firmware current.
- Configure DNS inside the VPN app when a VPN is used.
- Put family filtering on the device, not only the router.
- Leave managed work devices on the employer's resolver.
Standards and references
- IETF: RFC 7858 Specification for DNS over Transport Layer Security (TLS)
- IETF: RFC 8310 Usage Profiles for DNS over TLS and DNS over DTLS
- IETF: RFC 8484 DNS Queries over HTTPS (DoH)
- IETF: RFC 9462 Discovery of Designated Resolvers
- Google: DNS over TLS support in Android P
- Apple: DNSSettings device management payload
- Microsoft Learn: DNS over HTTPS client support
- Mozilla: Trusted Recursive Resolver policy
Related NHI Mgmt Group resources: Encrypted DNS Enterprise Guide · DNS Security Guide · Securing Your Home Router Guide · Public Wi-Fi Safety Guide