How to Change DNS on a Chromebook in 2026

ChromeOS keeps DNS settings tucked deeper in the network stack than most operating systems, and Google reorganized that UI at least twice between 2023 and 2025. Whether you are switching to Cloudflare's 1.1.1.1 for privacy, using Google's 8.8.8.8 for reliability, or debugging a resolution failure that only happens on your Chromebook, this guide covers every method that works on current ChromeOS builds in 2026 — including the often-overlooked difference between system-level DNS and Chrome's own Secure DNS layer.

Why Change Your Chromebook's DNS Resolver

Out of the box, your Chromebook inherits DNS from your router, which almost always means your ISP's recursive resolvers. ISP resolvers are a poor default for three reasons: they are often slow (latency of 40–120 ms in many regions), they log every domain you query, and some ISPs deliberately return incorrect responses for failed lookups — redirecting NXDOMAIN results to their own ad pages rather than an honest error.

Switching to a third-party resolver addresses all three. Common motivations:

• Speed: Google (8.8.8.8) and Cloudflare (1.1.1.1) run anycast infrastructure close to most users and benchmark consistently under 20 ms globally.
• Privacy: Cloudflare's 1.1.1.1 commits to not logging query data for advertising. Learn how DNS works and why resolver choice affects your privacy.
• Filtering: Quad9 (9.9.9.9) blocks known malware domains at the resolver level. OpenDNS FamilyShield (208.67.222.123) adds content filtering for families.
• Fixing broken ISP resolution: Some ISPs return wrong results for valid domains — a practice called DNS hijacking. Switching resolvers often fixes this instantly.
• DNSSEC validation: Both 1.1.1.1 and 8.8.8.8 validate DNSSEC signatures, returning SERVFAIL for tampered records instead of silently serving manipulated data.

Two Separate DNS Layers on ChromeOS

ChromeOS has two independent DNS paths that can point to completely different resolvers. Conflating them is the most common reason a DNS change appears to do nothing.

Layer 1 — System DNS (per Wi-Fi network): Configured inside ChromeOS Settings under your Wi-Fi connection properties. These resolvers handle all DNS queries from the operating system: Android apps, Linux containers, ChromeOS system updates, and the Chrome browser when Chrome's own Secure DNS is inactive or has fallen back. This is the resolver visible in /etc/resolv.conf inside a Linux terminal on the device.

Layer 2 — Chrome Secure DNS (DNS-over-HTTPS): Configured inside Chrome's Privacy and Security settings. When active, Chrome sends encrypted DNS-over-HTTPS (DoH) queries directly to its configured provider, completely bypassing Layer 1 for browser tab traffic. Android apps, the Linux container, and all ChromeOS system processes still use Layer 1 regardless of what Layer 2 is set to.

Most users should change Layer 1 — it covers the entire device. If you only care about browser-tab privacy and do not run Android or Linux apps that require specific DNS behavior, Layer 2 alone is sufficient. For complete, device-wide coverage, set both.

Method 1 — Change System DNS Per Wi-Fi Network

This is the reliable, device-wide approach. ChromeOS saves DNS settings per saved Wi-Fi network profile, so repeat this for every network you use regularly: home, work, mobile hotspot.

Step-by-Step for ChromeOS 120 Through 134 (2024–2026 Stable Channel)

1. Click the system clock in the bottom-right corner to open Quick Settings.
2. Click the gear icon to open the full Settings app.
3. In the left sidebar, click Network, then click Wi-Fi.
4. Click the name of your connected network. The network detail panel opens.
5. At the top of the panel, click the Network tab (alongside Proxy and Security).
6. Scroll to the Name Servers section. The default dropdown shows Automatic name server.
7. Open the dropdown and select Custom name server. (Select Google name server to set 8.8.8.8 and 8.8.4.4 without manual entry.)
8. Enter your resolver IPs in the Name Server 1 and Name Server 2 fields that appear.
9. Press Enter or click elsewhere. ChromeOS saves immediately — no Apply button needed.
10. Disconnect and reconnect to the network. New resolvers take effect on the next connection, not mid-session.

Standard resolver pairs:

• Cloudflare (privacy-focused): 1.1.1.1 and 1.0.0.1
• Google (reliable, globally distributed): 8.8.8.8 and 8.8.4.4
• OpenDNS (content filtering): 208.67.222.222 and 208.67.220.220
• Quad9 (malware blocking): 9.9.9.9 and 149.112.112.112

What the Automatic Setting Actually Does

When Name Servers is set to Automatic, ChromeOS reads resolver IPs from DHCP option 6 — the DNS server value your router advertises in its lease offers. Changing DNS at the router level affects every device on the network simultaneously. The per-device ChromeOS setting overrides the router-supplied value for that Chromebook only, which is useful when you want different DNS behavior than the rest of the household.

Important: there is no single system-wide DNS override in ChromeOS that covers all saved networks at once. Each saved network profile has its own Name Servers setting. If you forget to set custom DNS on your work Wi-Fi, queries there still use the router-supplied resolver.

Method 2 — Chrome Secure DNS (DNS-over-HTTPS)

Chrome's built-in DoH implementation encrypts DNS queries for all browser tab traffic. It operates completely independently of the system DNS layer set in Method 1 and does not affect Android apps, the Linux container, or ChromeOS system processes.

1. Open Chrome and navigate to chrome://settings/security
2. Scroll to the Advanced section and find Use secure DNS.
3. Toggle it on if it is not already active.
4. Below the toggle, switch the provider from With your current service provider to With [Custom].
5. Enter the DoH endpoint URL for your chosen resolver in the field that appears.

DoH endpoint URLs for common providers:

• Cloudflare: https://cloudflare-dns.com/dns-query
• Google: https://dns.google/dns-query
• Quad9: https://dns.quad9.net/dns-query

Chrome validates the endpoint on focus-out. The field turns red if the URL is not a working DoH endpoint. You can paste the URL into a browser tab to confirm it is reachable — a valid DoH endpoint returns a JSON response or an HTTP 400, both of which confirm the service is live.

Automatic DoH Upgrade

When Secure DNS is left on With your current service provider, Chrome automatically upgrades to DoH if it detects the current resolver supports it. Both 8.8.8.8 and 1.1.1.1 support automatic upgrade. If your Wi-Fi DNS is already pointed at either of those, Chrome may already be using DoH without any manual configuration on your part. Confirm at chrome://net-internals/#dns — look at the current resolver entry to see whether an HTTPS endpoint is active.

Setting IPv6 DNS Servers on ChromeOS

Most residential and business networks in North America have IPv6 connectivity in 2026. ChromeOS accepts IPv6 addresses in the Name Servers fields alongside IPv4 — both formats work in the same input fields without any mode switching.

IPv6 resolver addresses for major providers:

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

You can mix address families across the two Name Server fields — for example, Name Server 1: 1.1.1.1 and Name Server 2: 2606:4700:4700::1001. ChromeOS will use whichever address is reachable. For simplicity, most home users set both fields to IPv4 addresses. This works correctly even on IPv6-enabled networks because IPv6 network connectivity and IPv6 DNS server support are independent configuration decisions.

Verify the Change Worked

Saving a DNS setting and actually using the new resolver are two different things. Run one of these checks immediately after making the change and reconnecting.

Using Crosh (No Linux Required)

Press Ctrl+Alt+T anywhere in ChromeOS to open Crosh, the built-in diagnostic shell. It includes a basic DNS lookup command:

The output shows the resolved IP address and the responding server. Confirm the server IP shown matches your new resolver.

To test IP connectivity and name resolution separately:

If pinging the IP address succeeds but pinging the hostname fails, the new resolver is reachable but DNS is not resolving queries yet. Disconnect and reconnect the Wi-Fi network, then retry both commands.

Using the Linux Terminal (Crostini)

If Linux is enabled on your Chromebook, open the Linux terminal for detailed DNS inspection:

To confirm what resolver the system layer is configured to use:

The nameserver line in that file reflects the ChromeOS host resolver pushed into the container. If you set system DNS to 1.1.1.1 at the Wi-Fi level, you should see nameserver 1.1.1.1 here. If you still see your router's IP (typically 192.168.1.1 or 10.0.0.1), the ChromeOS DNS change has not taken effect — verify that you disconnected and reconnected after saving.

Managed Chromebooks — School and Enterprise Devices

If your Chromebook is enrolled in a Google Workspace organization, administrators can lock DNS settings at the policy level. Signs your device is managed:

• The Name Servers dropdown in Wi-Fi settings is greyed out or absent
• Chrome's Secure DNS toggle is missing from chrome://settings/security
• A message reading Managed by your organization appears at the bottom of Settings

To inspect active policies, navigate to chrome://policy in Chrome. Relevant entries:

• DnsOverHttpsMode set to off — DoH is administratively disabled
• BuiltInDnsClientEnabled set to false — Chrome is forced to use the OS resolver with DoH disabled
• DnsOverHttpsTemplates — if populated, DoH is locked to a specific administrator-controlled endpoint

There is no user-level workaround when these policies are enforced at the OS layer. For school devices, contact your network administrator. Wiping the device and un-enrolling removes all policies but also removes access to managed school resources — not an appropriate option for school-issued hardware.

Common Misdiagnoses

Changed DNS but the site is still blocked or unreachable

DNS is one hop in the chain, not the whole connection. If a site remains unreachable after switching resolvers, the block may be at the IP level — a firewall blocking the destination IP address directly, not via domain name — a CDN geo-restriction, or a content filter running at your router independently of DNS. In Crosh, run ping 8.8.8.8 to test raw IP connectivity, then ping google.com to test name resolution. If the IP ping fails, the issue is your network path, not DNS.

The DNS setting disappears after reboot

ChromeOS saves DNS per network profile, keyed by SSID and BSSID. If your router broadcasts the same SSID on both 2.4 GHz and 5 GHz, ChromeOS may treat them as distinct profiles. The DNS change you applied to the 5 GHz connection does not carry over to the 2.4 GHz connection. Set custom DNS on each band's saved profile separately, or enable band steering at the router to present both bands as a single network.

Chrome shows a different DNS resolver than the system

This is expected and intentional. Chrome's Layer 2 DoH resolver operates independently of the system's Layer 1 resolver, and they can legitimately differ. Navigate to chrome://net-internals/#dns to see which resolver Chrome is using for browser tabs. Run dns_lookup in Crosh to see what the system resolver is. The two are separate paths by design.

Custom DNS entered but queries still reach the old resolver

The most frequent cause is forgetting to disconnect and reconnect after saving. ChromeOS does not flush DNS mid-connection; the new resolver only takes effect on the next DHCP handshake. If reconnecting does not help, try forgetting the network entirely — click the gear icon next to the network name in Wi-Fi settings, then Forget — and reconnect from scratch.

How to Revert to Automatic DNS

To restore DHCP-supplied DNS: open Settings → Network → Wi-Fi → click the network name → Network tab → Name Servers dropdown → select Automatic name server. Disconnect and reconnect. ChromeOS will read resolver IPs from your router's DHCP lease again on the next connection, and the custom settings are cleared for that network profile.

2026 Notes — DoH, DoT, and DNSSEC on ChromeOS

DoH Is On by Default for Most ChromeOS Setups Since 2024

Since ChromeOS 122, released in early 2024, new Chromebook setups default Chrome's Secure DNS to automatic mode rather than off. If your current system DNS resolver supports DoH — both 1.1.1.1 and 8.8.8.8 do — Chrome is already upgrading to DoH automatically for browser traffic without any manual configuration. Check chrome://settings/security before setting up DoH manually. You only need to configure it explicitly if you want to force a specific provider rather than letting Chrome auto-detect and upgrade.

DoT Not Available at the System Level

DNS-over-TLS (port 853) is not available as a ChromeOS system DNS option in the 2026 stable channel. DNS-over-HTTPS via Chrome remains the only built-in encrypted DNS path for most users. Users running Linux via Crostini can install stubby inside the Linux container to add DoT for container-level queries, but this does not affect the ChromeOS host OS DNS layer or Android app DNS.

DNSSEC Is Handled at the Resolver Level

ChromeOS does not perform DNSSEC validation natively in the OS. It relies on the configured resolver to do so. Cloudflare 1.1.1.1 and Google 8.8.8.8 both validate the full DNSSEC chain-of-trust and return SERVFAIL for domains with broken or missing signatures. Switching to either resolver gives effective DNSSEC protection without any additional device-level configuration required.

Happy Eyeballs and IPv6 Resolver Latency

ChromeOS implements Happy Eyeballs (RFC 8305) to prefer IPv6 connections when connecting to dual-stack destinations. Both Cloudflare and Google operate fast IPv6 anycast resolver infrastructure globally, so resolver latency over IPv6 is comparable to IPv4 for either provider. If you switch to a less common resolver and notice occasional slow first lookups, test whether using that provider's IPv4 address specifically resolves the issue before assuming the resolver itself is at fault.