On iOS 18, you change the DNS server for a specific Wi-Fi network by going to Settings > Wi-Fi, tapping the (i) icon beside the network name, scrolling to the DNS section, tapping Configure DNS, and switching from Automatic to Manual. Each saved Wi-Fi network stores its own DNS configuration independently — editing one does not affect any other. For encrypted DNS that also covers cellular connections, a configuration profile is the correct tool rather than the per-network manual entry.
Why per-network DNS matters on iOS
Your iPhone sends a DNS query before almost every network request it makes. By default, the resolver is whatever the router handed out via DHCP — usually your ISP's own nameserver. That resolver may log every query, return ad-injected responses on NXDOMAIN, block legitimate sites in certain regions, or simply be slower than public alternatives. Configuring DNS per network lets you apply the right resolver for each context automatically:
- Home network: replace ISP-default DNS with a faster or privacy-focused resolver like Cloudflare 1.1.1.1 or Quad9 9.9.9.9.
- Office or school Wi-Fi: keep the local DNS server configured there so internal hostnames resolve correctly, while overriding DNS on every other network.
- Hotel or coffee shop Wi-Fi: use a trusted resolver to avoid captive-portal DNS hijacking that serves ads or restricts access to sites.
- Development and testing: point a single test device at a staging or split-horizon nameserver without touching other devices on the same network.
- Parental filtering: configure a filtering resolver on a shared home SSID to block malicious or adult domains at the DNS layer with no per-device software required.
Because the setting is stored in the saved network profile, iOS switches resolver automatically when you join that network. No manual toggle is needed each time you connect.
How to change DNS on a Wi-Fi network in iOS 18
You must have previously joined the network for its detail screen to be accessible. These steps apply to any iPhone or iPad running iOS 18 or iPadOS 18.
- Open Settings.
- Tap Wi-Fi.
- Locate the network and tap the (i) circle at the right edge of that row. Do not tap the network name itself — that triggers a connection or disconnection. The (i) icon opens the network detail screen.
- Scroll past the IP address, subnet mask, and router fields to the DNS heading.
- Tap Configure DNS. The current value reads Automatic.
- Tap Manual. iOS copies the DHCP-assigned DNS addresses into the editable list as a starting point.
- Tap Add Server and type your preferred resolver address.
- Tap Add Server again and add a secondary address for fallback redundancy.
- Remove the pre-filled ISP entries: tap the red minus button beside each one, then tap Delete to confirm. Leaving them in place means iOS may still fall back to the ISP resolver when your preferred server does not respond immediately.
- Tap Save in the top-right corner.
The change takes effect immediately without reconnecting or rebooting. iOS expires the local DNS cache within seconds. If you test a domain immediately after saving and still see the old result, wait five to ten seconds and try again — no further action is needed.
Choosing a DNS resolver
Unless you have a specific reason to run your own resolver, one of the established public options is the right starting point. The differences that matter for a mobile device:
- Cloudflare 1.1.1.1 / 1.0.0.1: consistently ranks among the fastest in independent latency benchmarks. Does not sell query data. Supports DoH and DoT. IPv6 addresses: 2606:4700:4700::1111 and 2606:4700:4700::1001.
- Google Public DNS 8.8.8.8 / 8.8.4.4: extremely reliable with a large global cache and high uptime history. Logs some query data for abuse analysis. Supports DoH and DoT. IPv6: 2001:4860:4860::8888 and 2001:4860:4860::8844.
- Quad9 9.9.9.9 / 9.9.9.10: validates DNSSEC by default and blocks known malicious domains using threat intelligence feeds. Operated by a non-profit. IPv6: 2620:fe::fe and 2620:fe::9.
- NextDNS: customizable filtering dashboard — block ads, trackers, and specific domain categories. Free tier with a monthly query limit; paid tier for unlimited queries. Works well as a DoH profile for iOS.
- AdGuard DNS 94.140.14.14 / 94.140.15.15: ad and tracker blocking at the DNS layer with no additional software. Also offers a family-protection variant with adult content filtering.
For a straightforward privacy improvement with no content filtering, Cloudflare 1.1.1.1 is a reliable default. For automatic malware blocking with DNSSEC validation included, Quad9 9.9.9.9 is the better choice.
Adding IPv6 DNS server addresses
If the network has IPv6 connectivity — most home broadband connections and carrier networks do by 2026 — add IPv6 resolver addresses in the same Configure DNS list alongside the IPv4 ones. iOS manages both address families through the same interface; enter IPv6 addresses in standard colon-hex notation exactly as shown in the previous section. On a network without IPv6 routing, iOS silently skips IPv6 entries and falls back to the IPv4 resolvers. Including both families ensures the correct resolver is reachable regardless of how the upstream network is provisioned, which is particularly relevant on carrier Wi-Fi offload segments that may be IPv6-only.
Encrypted DNS on iOS 18: DoH and DoT via configuration profiles
The manual entry method sends DNS queries over plain UDP port 53. Those queries are visible to anyone on the network path — the router, the ISP, and any party performing traffic inspection on shared Wi-Fi. iOS 18 supports DNS over HTTPS (DoH) and DNS over TLS (DoT) through signed .mobileconfig configuration profiles installed at the system level. Once in place, these profiles enforce encrypted resolution without any per-app or per-network configuration.
Providers including Cloudflare, NextDNS, Quad9, and AdGuard publish official profiles. Installation:
- Download the provider's .mobileconfig file in Safari. iOS prompts: This website is trying to download a configuration profile. Do you want to allow this? Tap Allow.
- Open Settings > General > VPN & Device Management.
- Tap the profile listed under Downloaded Profile.
- Tap Install and enter your device passcode.
- Tap Install on the warning screen, then Done.
A system-wide DoH or DoT profile overrides per-network manual DNS entries configured in the Wi-Fi menu — the manual entries remain visible but the profile resolver handles actual queries. Some provider profiles can restrict themselves to specific Wi-Fi SSIDs; check the provider's documentation for details. To remove a profile: Settings > General > VPN & Device Management, tap the profile name, tap Remove Profile.
Changing DNS on cellular (LTE and 5G)
iOS 18 does not expose a DNS override field in the cellular settings menu. Carrier DNS is assigned through the APN configuration and is not user-editable through Settings > Cellular. The practical options for a custom resolver on mobile data are:
- System-wide DoH/DoT configuration profile: a profile installed via Settings applies to all interfaces including cellular. This is the most straightforward option for consistent DNS across both Wi-Fi and mobile data without requiring a persistent VPN.
- Full-tunnel VPN: a VPN that routes all traffic through a remote tunnel also controls DNS for that session. Split-tunnel VPNs vary — confirm in the client's documentation whether DNS queries go through the tunnel or resolve locally.
- Third-party DNS apps: apps such as the Cloudflare 1.1.1.1 app and NextDNS create a local VPN profile that intercepts only DNS queries without routing other traffic through a remote server. They appear as an active VPN connection in Settings but do not add latency to browsing or streaming traffic.
Verifying that the change took effect
iOS has no built-in terminal, so running dig or nslookup directly on the device requires either a second machine on the same network or a third-party iOS app. Verification is worth doing — the settings screen showing Manual DNS does not guarantee the router is not intercepting queries before they reach your chosen resolver.
From a Mac connected to the same Wi-Fi
Open Terminal and query your configured resolver directly:
A valid IP address in the response confirms the resolver is reachable and answering. Replace 1.1.1.1 with the address you configured. A timeout means either the address was entered incorrectly in iOS, or the router is blocking outbound port 53 to external addresses — a sign that transparent DNS proxying is active.
From the iOS device using a third-party app
Apps such as Network Analyzer, available on the App Store, include a DNS lookup function. Enter a domain, specify the resolver to query, and compare the result to what a default resolver returns. No special device permissions are required and the app does not need to be left running.
DNS leak test
In Safari, visit a DNS leak test service. The page sends multiple queries and reports which resolver IP answered them. After configuring Cloudflare, you should see a Cloudflare-owned IP — not your ISP's address range. After configuring Quad9, responses should come from the 9.9.9.0/24 block. If the test still shows your ISP's resolver, either the manual entry was not saved, or the router is transparently intercepting port 53 queries.
Common mistakes and misdiagnoses
Tapping the network name instead of the (i) icon
In the Wi-Fi list, tapping the SSID text triggers a connection change action — it does not open a settings screen. DNS configuration is only accessible through the small (i) button at the right edge of the row. This single UI detail is the most common reason users report they cannot locate the DNS setting in iOS 18.
Leaving pre-filled ISP servers in the list
When switching to Manual, iOS pre-populates the server list with whatever DHCP assigned — typically the router's own IP or the ISP's nameserver. Adding your preferred server without removing the pre-filled entries leaves the ISP servers in the rotation. iOS may query them when your preferred resolver does not respond within its timeout window. Remove all pre-filled entries you do not intend to use before saving.
Router transparent DNS proxy intercepting port 53
Some consumer routers intercept all outbound UDP and TCP traffic on port 53 and redirect it to themselves regardless of what the client specifies as its resolver. This feature is sometimes called DNS proxy, transparent DNS, or DNS rebind protection depending on the firmware. If you configure a custom DNS address but a leak test still reports your ISP's resolver, transparent interception is the most likely cause. The reliable workaround is a DoH or DoT configuration profile — both operate over port 443, which routers almost never intercept. Alternatively, look in the router's administration panel for a DNS proxy or intercept setting and disable it; the exact path varies by brand and firmware version, so consult the manufacturer's support documentation for your specific model.
Captive portal phase overriding custom DNS
When first connecting to a hotel, airport, or coffee shop network, iOS must pass through a captive portal sign-in before normal traffic proceeds. During this phase the network overrides DNS to redirect HTTP requests to the portal page. Your custom resolver settings activate only after the portal is dismissed. If the portal page is not loading, temporarily set Configure DNS back to Automatic, complete the sign-in, then restore your Manual configuration and tap Save again.
DoH profile silently taking precedence over the per-network entry
If a DoH or DoT configuration profile is already installed — perhaps placed there by a provider app during an earlier setup — it takes precedence over any per-network manual DNS entry. The Wi-Fi detail screen continues to show your manual entries as saved, but the profile resolver handles actual queries. Before concluding a manual entry is not working, check Settings > General > VPN & Device Management for installed profiles.
When settings revert to Automatic
Per-network DNS entries persist as long as the saved network profile exists on the device. They reset in these specific situations:
- Forgetting and re-joining the network: using Forget This Network removes the entire saved profile including DNS settings. Reconfigure after re-joining.
- SSID rename: if the router is renamed after a firmware update or admin change, iOS creates a new saved profile for the new SSID with Automatic DNS. The old custom settings are orphaned under the old network name and will not apply.
- Device restore from scratch: erasing the device and setting up as new removes all saved network profiles. Restoring from an iCloud backup or an encrypted local iTunes/Finder backup recovers them.
- MDM-managed device: on a device enrolled in Mobile Device Management — common on corporate iPhones and school iPads — the MDM server can push DNS policies that override any user-configured setting. This cannot be circumvented without unenrolling from MDM.
2026 considerations: IPv6-only segments, encrypted DNS, and DNSSEC
IPv6-only access networks — where the router assigns only IPv6 addresses and provides IPv4 connectivity through NAT64 — are more prevalent in 2026 than in prior years, particularly on carrier Wi-Fi offload and some residential ISP rollouts. On such networks, a plain IPv4 resolver entry like 8.8.8.8 may be unreachable unless the router performs NAT64 synthesis for that address. Adding the IPv6 address of the same resolver alongside the IPv4 entry in the Configure DNS list prevents resolution failures on these segments. For example, pairing 8.8.8.8 with 2001:4860:4860::8888 covers both network types.
DNS over HTTPS has become the practical standard for private mobile DNS in 2026. The Google Public DNS documentation and equivalent resources from Cloudflare and Quad9 all publish DoH endpoints and iOS-compatible .mobileconfig profile files. For any scenario where query privacy matters — public Wi-Fi, shared office networks, international travel — a DoH profile is more robust than a plain UDP manual entry because it operates over port 443, encrypts query content in transit, and cannot be silently intercepted at the router level the way port 53 traffic can.
DNSSEC validation on iOS is performed by the configured resolver, not the device itself. Choosing a validating resolver such as Quad9 — which validates DNSSEC by default for every query — means cryptographically forged or tampered DNS responses are rejected before they reach the phone. iOS 18 has no on-device DNSSEC validation toggle. The resolver you specify in Configure DNS is the entire control point for DNSSEC coverage, which makes resolver selection more consequential than it might initially appear.