Google Public DNS: 8.8.8.8, 8.8.4.4, IPv6 addresses and how to set them

Short answer: Google Public DNS is a free recursive DNS resolver run by Google. Its addresses are 8.8.8.8 and 8.8.4.4 for IPv4 and 2001:4860:4860::8888 and 2001:4860:4860::8844 for IPv6. Enter them as the DNS servers of your network adapter, phone or router, and your name lookups go to Google instead of your provider’s resolver.

All of these come from Google’s own Public DNS documentation (pages last updated 3 September 2024, read 21 October 2026). Google warns that the DNS64 pair is only for networks that can reach a NAT64 gateway; anywhere else, use the normal addresses.

What is 8.8.8.8?

8.8.8.8 is the primary address of Google Public DNS, a service Google has run since December 2009. It is a recursive resolver: when your computer asks it for example.com, it walks the DNS tree from the root servers down to the domain’s own nameservers, caches the answer and hands it back. Your internet provider runs a resolver that does the same job, and that is what your devices use by default, because the router hands its address out over DHCP.

The address is anycast: the same 8.8.8.8 is announced from many Google locations, and routing carries your query to a nearby one, which keeps the round trip short in most regions. It needs no account, costs nothing and its reverse DNS name is dns.google. 8.8.4.4 is the second address of the same service, there so that a lookup still works if one address is unreachable from your network. The general mechanics of resolvers, caching and TTLs are in what is DNS.

Google DNS is not a domain’s nameservers

People searching for “Google nameservers” often mix up two different roles. Google Public DNS is a resolver: it looks names up for clients. A domain’s nameservers are authoritative servers: they hold the domain’s records and answer for it. 8.8.8.8 holds no zone of yours and cannot be entered at a registrar as a domain’s nameserver.

• To change which resolver a device uses, set 8.8.8.8 in its network settings (the rest of this guide).
• To change where a domain’s records live, you change its nameservers at the registrar, to whoever hosts the zone: the registrar itself, a DNS provider or your own servers. That is a different setting, explained in what are nameservers.
• Google does run authoritative DNS too, but as separate services: the zone of google.com itself is served by ns1.google.com to ns4.google.com, and Google Cloud DNS, its paid hosting service, gives each zone nameservers under googledomains.com. None of them is 8.8.8.8.

What does Google log?

Google describes its logging on the Google Public DNS privacy page (last updated 3 September 2024, read 21 October 2026). In short, as Google states it:

• Temporary logs hold the IP address of the device that sent the query, and Google deletes them within 24 to 48 hours, except where it keeps data longer to deal with security and abuse problems.
• Permanent logs are a sample of the temporary logs with the IP address removed and replaced by a city or region-level location. They keep the domain names, request types and protocols.
• Google says it does not correlate the Public DNS logs with your information from other Google services, except for security and abuse.

One more thing reaches third parties: Google’s documentation says it sends EDNS Client Subnet (ECS), a shortened form of your network address, to authoritative servers it detects as supporting it, so that content networks can answer with a server near you. Encrypting the hop with DoH or DoT hides your lookups from the local network and your provider, not from Google. Choosing a resolver is choosing whom you trust with the list of names you look up; read each provider’s own policy rather than a summary.

How to set Google DNS on Windows

Windows 11: Settings → Network & internet → Ethernet (or Wi-Fi → your network) → DNS server assignment → Edit → Manual. Turn on IPv4, enter 8.8.8.8 as Preferred DNS and 8.8.4.4 as Alternate DNS, then do the same under IPv6 with the two IPv6 addresses. Windows 11 knows Google’s DoH template, so the DNS over HTTPS menu next to each address can be switched on as well.

Windows 10 and Windows Server: press Win+R, run ncpa.cpl, right-click the adapter → Properties → Internet Protocol Version 4 (TCP/IPv4) → Properties → “Use the following DNS server addresses”. Repeat for Internet Protocol Version 6. In PowerShell as Administrator, the same change for both families is one line:

Get-NetAdapter | Where-Object Status -eq 'Up'     # the adapter name: Ethernet, Wi-Fi ...

Set-DnsClientServerAddress -InterfaceAlias 'Ethernet' -ServerAddresses ('8.8.8.8','8.8.4.4','2001:4860:4860::8888','2001:4860:4860::8844')
Clear-DnsClientCache
Get-DnsClientServerAddress -InterfaceAlias 'Ethernet'
Resolve-DnsName example.com

# back to the servers DHCP hands out
Set-DnsClientServerAddress -InterfaceAlias 'Ethernet' -ResetServerAddresses

netsh interface ipv4 set dnsservers name="Ethernet" source=static address=8.8.8.8 register=primary
netsh interface ipv4 add dnsservers name="Ethernet" address=8.8.4.4 index=2

Changing DNS servers does not change the server’s IP address, so it is safe to do over a Remote Desktop session. One exception on Windows Server: a machine joined to Active Directory, or a domain controller, must keep pointing at the domain controllers. Google cannot resolve your internal AD zone, and logons and Group Policy start failing. If DNS stops working after the change, see DNS server not responding.

How to set Google DNS on a Mac

System Settings → Network → Wi-Fi (or Ethernet) → Details → DNS. Click + under DNS Servers, add the four addresses, and click OK. In Terminal:

networksetup -listallnetworkservices
sudo networksetup -setdnsservers Wi-Fi 8.8.8.8 8.8.4.4 2001:4860:4860::8888 2001:4860:4860::8844
networksetup -getdnsservers Wi-Fi
sudo networksetup -setdnsservers Wi-Fi empty     # back to the DHCP servers

How to set Google DNS on Linux

Start by finding out who writes /etc/resolv.conf, because on most current systems it is generated and a hand edit is overwritten at the next reboot or DHCP renewal:

ls -l /etc/resolv.conf
# -> ../run/systemd/resolve/stub-resolv.conf  : systemd-resolved (Ubuntu, many Debian images)
# "# Generated by NetworkManager" inside      : NetworkManager (desktops, Rocky, AlmaLinux)
# a plain file you wrote yourself             : edit it directly

Ubuntu and Debian with netplan

Set the servers on the interface that carries your traffic (ip -br link shows its name). If that interface uses DHCP, also tell netplan to ignore the DHCP-provided DNS servers, or they stay in use next to Google’s:

network:
  version: 2
  ethernets:
    eth0:
      # keep your existing addresses, routes and dhcp4 lines as they are
      dhcp4-overrides:
        use-dns: false            # only needed when dhcp4: true
      nameservers:
        addresses: [8.8.8.8, 8.8.4.4, "2001:4860:4860::8888", "2001:4860:4860::8844"]

sudo netplan try          # rolls back after 120 seconds unless you confirm
sudo netplan apply
resolvectl status eth0     # "DNS Servers:" should list the Google addresses

A file named 50-cloud-init.yaml was written by cloud-init and can be regenerated; how to make the change stick is in the netplan part of Temporary failure in name resolution. For a quick test that is gone after the next restart, sudo resolvectl dns eth0 8.8.8.8 8.8.4.4 changes the servers of one interface immediately.

systemd-resolved with DNS over TLS

systemd-resolved can encrypt every lookup to Google with DoT. The #dns.google after each address is the name the TLS certificate is checked against, as resolved.conf(5) documents it (read on Debian 12, systemd 252):

[Resolve]
DNS=8.8.8.8#dns.google 8.8.4.4#dns.google 2001:4860:4860::8888#dns.google 2001:4860:4860::8844#dns.google
DNSOverTLS=yes

sudo systemctl restart systemd-resolved
resolvectl status          # the Protocols line should show +DNSOverTLS
resolvectl query example.com

Two details from the same man page. Servers in DNS= are used in parallel with the per-interface servers from DHCP, and with DNSOverTLS=yes every lookup sent to a server without DoT support fails. So remove the DHCP servers first (the use-dns: false above), and make sure outbound TCP port 853 is not blocked.

NetworkManager (nmcli)

nmcli connection show                              # the connection name
sudo nmcli connection modify "Wired connection 1" ipv4.dns "8.8.8.8 8.8.4.4" ipv4.ignore-auto-dns yes
sudo nmcli connection modify "Wired connection 1" ipv6.dns "2001:4860:4860::8888 2001:4860:4860::8844" ipv6.ignore-auto-dns yes
sudo nmcli connection up "Wired connection 1"

ignore-auto-dns yes is what stops DHCP from adding its own servers back. connection up re-activates the connection, which can drop an SSH session for a moment; run it from the console if the machine is remote.

Android Private DNS and iPhone

Android 9 and newer: Settings → Network & internet → Private DNS → Private DNS provider hostname, enter dns.google and save (on Samsung phones: Connections → More connection settings → Private DNS). That is DNS over TLS for every network the phone uses, Wi-Fi and mobile data. Enter the hostname, not 8.8.8.8: Private DNS expects a hostname. A network that blocks port 853 then shows “Private DNS server cannot be accessed”, and lookups fail until you switch back to Automatic.

iPhone and iPad: Settings → Wi-Fi → the (i) next to your network → Configure DNS → Manual. Remove the existing entries, add 8.8.8.8 and 8.8.4.4 (and the IPv6 pair), then Save. This applies to that Wi-Fi network only; iOS has no such setting for mobile data.

Setting it on the router

Setting Google DNS on the router covers every device on the network at once. Open the router’s admin page (often 192.168.0.1 or 192.168.1.1), find the DNS fields under Internet, WAN or DHCP settings, and enter 8.8.8.8 and 8.8.4.4. Two things decide whether it actually works:

• WAN DNS vs DHCP DNS. Many routers keep handing out their own address as the DNS server and forward lookups to the WAN DNS servers you set. That is fine. Setting Google in the DHCP fields instead makes devices ask Google directly.
• IPv6. If the provider gives you IPv6, the router may also announce the provider’s IPv6 resolvers, and devices happily use those. Set the IPv6 DNS fields too, or the change only half applies.

Some provider routers lock the DNS fields. Then set the servers on each device instead, or use your browser’s own setting: Chrome has Settings → Privacy and security → Security → Use secure DNS → Google (Public DNS), and in Firefox you can enter https://dns.google/dns-query as a custom DNS over HTTPS provider. A browser setting affects that browser only.

How to test that you are using Google DNS

First ask 8.8.8.8 directly, which proves it is reachable from your network. This is a real run from a Debian 12 server on 21 October 2026:

dig @8.8.8.8 example.com

; <<>> DiG 9.18.49-1~deb12u2-Debian <<>> @8.8.8.8 example.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14498
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;example.com.			IN	A

;; ANSWER SECTION:
example.com.		300	IN	A	104.20.23.154
example.com.		300	IN	A	172.66.147.243

;; Query time: 7 msec
;; SERVER: 8.8.8.8#53(8.8.8.8) (UDP)
;; WHEN: Wed Oct 21 19:44:33 UTC 2026
;; MSG SIZE  rcvd: 72

• status: NOERROR and an answer section: the resolver answered. A timeout instead (no servers could be reached) means your network blocks outbound DNS to outside resolvers.
• The ad flag: Google validated the answer with DNSSEC.
• 300 is the TTL in seconds, and SERVER: 8.8.8.8#53 confirms who answered.

Then check that your system really uses Google when no server is named:

# Linux with systemd-resolved
resolvectl status | grep -E 'Current DNS|DNS Servers'

# Windows PowerShell
Get-DnsClientServerAddress -AddressFamily IPv4
nslookup example.com                # "Server: dns.google" means Google answers

# macOS
scutil --dns | grep nameserver

# DoH from a script, via Google's JSON API ("Status": 0 means NOERROR)
curl -s 'https://dns.google/resolve?name=example.com&type=A'

dig through the local stub shows SERVER: 127.0.0.53 on Ubuntu, which is systemd-resolved, not a sign that Google is unused; resolvectl status tells you what sits behind it. The nslookup command guide covers the Windows-side output in detail. After switching, old answers can stay in caches for their TTL, so flush the DNS cache of the OS and the browser if a site still resolves the old way.

Google DNS vs Cloudflare, Quad9 and OpenDNS

Addresses as each provider publishes them; they have not changed in years, but check the provider’s own page before you hard-code them anywhere. All four are free and anycast. Speed depends on where you are, so measure from your own network with dig @ADDRESS example.com a few times each and compare the Query time. Two practical rules: where a device takes only two servers, consider two different providers, so one outage cannot take out both; and if you want malware filtering, pick Quad9 or Cloudflare’s filtered address, because Google offers none.

Google DNS on a VPS or dedicated server

On a server the default is fine for most workloads: keep the resolvers the provider sets, or set a public pair in netplan as above. On a VMHeaven VPS, cloud-init sets Cloudflare and Quad9 (1.1.1.1 and 9.9.9.9) at installation and again on every reinstall, so a hand change in netplan or /etc/resolv.conf may need repeating after a reinstall. Swapping in Google’s pair changes nothing about the server’s own address or routing.

When you change a domain’s records rather than the server’s resolver, Google is one of the caches that has to catch up. The DNS propagation checker asks Google and other public resolvers the same question at once and shows which still return the old answer.

Frequently asked