How do I set custom DNS on Google Wifi?

Open the Google Home app, tap your Wi-Fi network, navigate to Settings → Advanced networking → DNS, switch from Automatic to Custom, and enter your preferred DNS server addresses. The router applies the change network-wide within seconds; individual devices may need to renew their DHCP lease to reflect the update immediately. Google Wifi and Nest Wifi expose DNS configuration only through the Google Home app — there is no browser-based admin panel at a LAN IP address for this setting.

Why Change DNS on Google Wifi

Google Wifi ships with Google Public DNS (8.8.8.8 / 8.8.4.4) as the default upstream resolver when DNS mode is set to Automatic. Switching to a third-party resolver serves three practical purposes:

• Speed: Cloudflare's 1.1.1.1 and Quad9's 9.9.9.9 consistently outperform Google Public DNS in independent latency benchmarks from many North American ISP locations.
• Privacy: Cloudflare and Quad9 publish minimal-logging policies and both validate DNSSEC. Your ISP cannot inspect DNS queries when they are answered by a resolver outside ISP infrastructure.
• Filtering: OpenDNS and Quad9 block malware domains at the DNS layer. OpenDNS Family Shield (208.67.222.123 / 208.67.220.123) adds adult-content filtering for every device on the network without per-device software.

Setting Custom DNS in Google Home

The path below applies to the Google Home app on Android and iOS as of mid-2026. Google has reorganized this settings menu across several app updates; if a label does not match exactly, look for Advanced networking or Network settings under your router's gear icon.

1. Open the Google Home app and confirm you are signed into the account that owns the Google Wifi or Nest Wifi hardware.
2. Tap Wi-Fi in the bottom navigation bar to open your mesh network overview.
3. Tap the gear icon (Settings) at the top right of your network card.
4. Scroll down and tap Advanced networking.
5. Tap DNS.
6. Tap Custom to switch from Automatic mode.
7. Enter the primary DNS IP in the first field and the secondary IP in the second field.
8. Tap Save.

The change takes effect immediately on the router. To force a fast DHCP refresh on Windows, open an elevated Command Prompt and run:

On macOS, open Terminal and run (substitute en0 with your active interface name if different):

Which DNS Server Should You Use

The four most reliable public resolvers in 2026, with their IPv4 addresses and key characteristics:

• Cloudflare — 1.1.1.1 / 1.0.0.1: Fastest median response time in most independent benchmarks. Supports DNSSEC validation, DoH, and DoT. Minimal-logging policy published at cloudflare.com.
• Google Public DNS — 8.8.8.8 / 8.8.4.4: The factory default on Google Wifi. Globally reliable with anycast coverage. Useful as a baseline when diagnosing whether a custom DNS change caused a problem.
• Quad9 — 9.9.9.9 / 149.112.112.112: Blocks known malware, phishing, and exploit-kit domains using threat intelligence from over 20 industry partners. DNSSEC-validating. Operated by a Swiss non-profit that does not sell query data.
• OpenDNS Home — 208.67.222.222 / 208.67.220.220: Supports customizable category blocking via a free dashboard. The Family Shield variant (208.67.222.123 / 208.67.220.123) blocks adult content without an account.

For a household with children, Quad9 or OpenDNS Family Shield is the most practical choice. For a home lab or small business where latency matters most, Cloudflare is the standard recommendation. For pure ad-blocking at the DNS layer, use Pi-hole as the upstream (covered below) and point Pi-hole itself at Cloudflare or Quad9.

IPv6 DNS Addresses

If your ISP provides IPv6 connectivity, Google Wifi also accepts IPv6 DNS addresses in the same Custom DNS fields. The primary resolvers' IPv6 addresses are:

• Cloudflare: 2606:4700:4700::1111 / 2606:4700:4700::1001
• Google: 2001:4860:4860::8888 / 2001:4860:4860::8844
• Quad9: 2620:fe::fe / 2620:fe::9

To confirm whether your network uses routable IPv6, run the following on a Linux client:

If the output shows a global unicast address starting with 2 or 3, set IPv6 DNS as well. If not, IPv4 addresses are sufficient and the IPv6 field can be left empty. Many North American residential ISPs still provision dual-stack with IPv4 handling all authoritative lookups regardless of client address family.

Nest Wifi Pro and Secure DNS

Nest Wifi Pro, Google's Wi-Fi 6E mesh system, includes a Secure DNS toggle in the Advanced networking section of the Google Home app. When enabled, the router encrypts DNS queries using DNS over HTTPS (DoH), preventing ISP-level packet inspection of your query stream even when using a third-party resolver. Original Google Wifi hardware and first-generation Nest Wifi (2019) do not offer this feature — those models accept custom DNS IPs but send queries over standard unencrypted UDP/TCP port 53.

Secure DNS on Nest Wifi Pro works with the resolver presets available in the app. If you route DNS through a local server such as Pi-hole or AdGuard Home, disable Secure DNS entirely — a LAN IP address cannot serve DoH requests, and enabling Secure DNS with a LAN upstream IP causes silent resolution failures that are difficult to diagnose without checking the router's diagnostic output.

Verifying the Change from the Command Line

Do not assume the change took effect. Run one of these checks immediately after saving to confirm the router is forwarding to the correct upstream resolver.

Windows

Open Command Prompt or PowerShell and run:

The Server line will show your router's LAN IP (typically 192.168.86.1 on Google Wifi). This is expected — Google Wifi acts as a local DNS proxy and forwards to your custom upstream on behalf of all clients. To verify the upstream resolver is actually reachable, query it directly:

A valid TXT response from Cloudflare confirms 1.1.1.1 is accepting queries from your WAN connection.

macOS

Open Terminal and run:

The dig output confirms the upstream resolver responds. The scutil output shows your system-assigned DNS server — the router's LAN IP in a standard Google Wifi setup, which is correct behavior.

Linux

On systemd-resolved systems, check the per-interface DNS server and test the upstream directly:

A timeout on the dig command suggests an outbound port 53 block on the path. A response with IP addresses confirms the upstream is functioning correctly. If you see SERVFAIL instead of a clean answer, see the DNSSEC section below.

Android and iOS

Neither platform exposes a built-in DNS query tool. On Android 9 and later, Settings → Network and internet → Private DNS accepts a DoT hostname (such as one.one.one.one) that overrides the router's DNS for that device entirely. On iOS, per-device DNS overrides require a configuration profile or a VPN — there is no native DNS field in Wi-Fi network settings.

Common Problems and Misdiagnoses

The DNS option does not appear in the app

Advanced networking and its DNS sub-menu require an up-to-date Google Home app. Update from Google Play or the App Store, then relaunch the app. On mesh setups, the DNS option may only appear when you tap the primary router node specifically rather than a satellite point. Tap the individual router device in the app's device list rather than the top-level network name card.

The change appears to have no effect

Because Google Wifi advertises its own LAN IP to DHCP clients as the DNS server, clients never see the upstream resolver IP directly. The router handles forwarding internally. If behavior is unchanged after saving, restart the primary router node: Wi-Fi → Settings → Restart Wi-Fi. A restart flushes the router's internal DNS cache and reloads the upstream configuration. Reconnect a test device after the restart completes before retesting.

Certain devices ignore the router DNS

Smart TVs, many game consoles, and a large share of IoT devices hard-code their DNS settings — commonly pointing directly to 8.8.8.8 — and bypass the DHCP-assigned resolver entirely. Changing Google Wifi's upstream has no effect on these devices. Redirecting hard-coded DNS requires firewall-level port 53 interception, which is not available on stock Google Wifi firmware. Accept this limitation or place those devices on a separate network segment managed by a router or firewall that supports transparent DNS proxying.

DNSSEC validation failures after switching resolvers

Quad9 and Cloudflare both enforce strict DNSSEC validation. A small number of domains have misconfigured DNSSEC records that Google's resolver handles permissively but strict validators reject with SERVFAIL. If a specific site breaks after a resolver switch but loads fine on 8.8.8.8, test with:

A SERVFAIL response with no AD flag in the output indicates a broken DNSSEC chain on that domain, not a misconfiguration on your router. The fix is on the domain owner's side — their DS record or RRSIG is invalid. Revert temporarily to Google Public DNS and report the issue to the site operator.

Local DNS or Pi-hole not resolving internal hostnames

If Pi-hole is set as the Google Wifi upstream but is not configured to handle your internal zone, hostnames like nas.local or homeassistant.internal will fail. Under Pi-hole Settings → Local DNS → DNS Records, add entries for any internal hostnames that need to resolve. If you also have Secure DNS enabled on Nest Wifi Pro, disable it — Pi-hole does not serve DoH and Secure DNS with a LAN upstream produces silent resolution failures across the whole network.

Using Pi-hole as Your Google Wifi Upstream

Pi-hole is the most common reason home users set a custom DNS on Google Wifi. Two extra steps beyond entering the IP make the setup stable long-term:

1. Reserve the Pi-hole's IP address. In the Google Home app, go to Wi-Fi → Devices, find the Pi-hole device, tap it, and assign a static IP reservation. Without this, the Pi-hole can receive a new DHCP lease after a router reboot and your entire network loses DNS silently until you notice.
2. Set a public resolver as the secondary. Enter the Pi-hole's static LAN IP (e.g. 192.168.86.50) as the primary DNS and 1.1.1.1 or 9.9.9.9 as the secondary. If Pi-hole goes offline, the secondary keeps DNS working for all devices automatically until Pi-hole recovers.

Inside Pi-hole, configure the upstream resolvers under Settings → DNS → Upstream DNS Servers. Point them to Cloudflare or Quad9. This creates a clean resolution chain: client device → Google Wifi LAN proxy → Pi-hole (adblocking + local DNS) → Cloudflare or Quad9 → authoritative nameservers.

How to Confirm Everything Is Working

1. Open a terminal on a device connected to the Google Wifi network and run: dig @1.1.1.1 whoami.cloudflare.com txt +short — replace the IP with your chosen resolver. A valid TXT response confirms the upstream is reachable from your WAN IP.
2. Open a private browser window and load a site you have never visited. A successful page load confirms end-to-end DNS resolution is functioning.
3. If you switched to a filtering resolver, verify blocking is active by querying a domain on that resolver's blocklist with dig. An NXDOMAIN or REFUSED response confirms filtering is working as intended.
4. Run the same dig query twice, 30 seconds apart. The second response time should drop significantly (from roughly 20ms to under 5ms), confirming the router is caching upstream responses correctly and not issuing a fresh query on every lookup.

Preventing Future DNS Issues

• Always set two resolvers from different providers (Cloudflare primary, Quad9 secondary, for example) so a single-provider outage does not break DNS for the entire network.
• Keep static IP reservations current for any local DNS server. An IP change after a device replacement is the most common way Pi-hole deployments fail silently.
• Enable automatic firmware updates in the Google Home app under your router's settings. DNS-related fixes and new features such as Secure DNS arrive via firmware, not app updates.
• After any ISP modem or gateway replacement, revisit Advanced networking → DNS. Some modem-router combos in bridge mode push DHCP option 6 (DNS server override) that can silently reset your custom upstream on certain firmware versions.

What Changed in 2026: Browsers, DoH, and DNSSEC

By 2026, Chrome, Firefox, and Edge all enable DNS over HTTPS at the browser level by default. When a browser's built-in DoH is active, it resolves web domains through its own HTTPS resolver endpoint — bypassing the router's DNS entirely for browser traffic. This means custom DNS on Google Wifi primarily affects non-browser traffic: mobile app connections, system software updates, IoT devices, game consoles, smart home hardware, and command-line tools. For comprehensive coverage across both browser and non-browser traffic, either disable browser-level DoH in each browser's privacy settings and let the router handle all DNS, or configure both the router and browsers to point at the same resolver so filtering and logging remain consistent.

DNSSEC adoption has grown significantly at the resolver level. Both Cloudflare and Quad9 validate DNSSEC chains by default; Google Public DNS validates but applies more permissive fallback behavior for domains with broken signatures. If you manage any domain yourself, check your DNSSEC chain periodically — a broken DS or RRSIG record is invisible to users on Google's resolver but silently fails for users on Cloudflare or Quad9, producing intermittent SERVFAIL errors that are hard to trace back to the cause.

For the technical specification underlying all of the DNS behavior described in this article, the original DNS protocol standard (RFC 1035) is the authoritative reference. Sections 3.2 and 4.1 cover the query format and resource record structure that every resolver in this article implements at the wire level — reading them demystifies most of what Google Wifi is doing under the hood when it proxies your DNS queries.