What is Google Public DNS?
Google Public DNS is a free, global Domain Name System (DNS) resolution service, that you can use as an alternative to your current DNS provider.
Why is Google working on a DNS service?
We believe that a faster and safer DNS infrastructure could significantly improve the web browsing experience. Google Public DNS has made many improvements in the areas of speed, security, and validity of results. We've shared these improvements in our documentation, to contribute to an ongoing conversation within the web community.
Can I use Google Public DNS to host my domain name or website?
No. Google Public DNS is not an authoritative DNS hosting service. If you are looking for a high-volume, programmable, authoritative name server using Google's infrastructure, try Google's Cloud DNS.
Does Google Public DNS offer the ability to block or filter out unwanted sites?
No. Google Public DNS is purely a DNS resolution and caching server; it does not perform any blocking or filtering of any kind, except that it may not resolve certain domains in extraordinary cases if we believe this is necessary to protect Google’s users from security threats. But we believe that blocking functionality is usually best performed by the client. If you are interested in enabling such functionality, you should consider installing a client-side application or browser add-on for this purpose.
Are Googlers using Google Public DNS?
Yes. Googlers have been using Google Public DNS since a couple of months before the launch. Also, we have been using it to power our Wi-Fi networks for visitors as well as our free public Wi-Fi network in Mountain View, California.
Are there any cross-product dependencies with Google Public DNS?
Google Public DNS is an independent service.
Do I need a Google Account to use Google Public DNS?
How is Google Public DNS different from my ISP's DNS service or other open DNS resolvers? How can I tell if it is better?
Open resolvers and your ISP all offer DNS resolution services. We invite you to try Google Public DNS as your primary or secondary DNS resolver along with any other alternate DNS services. There are many things to consider when identifying a DNS resolver that works for you, such as speed, reliability, security, and validity of responses. Unlike Google Public DNS, some ISPs and open resolvers block, filter, or redirect DNS responses for commercial purposes.
How does Google Public DNS handle non-existent domains?
If you issue a query for a domain name that does not exist, Google Public DNS always returns an NXDOMAIN record, as per the DNS protocol standards. The browser should show this response as a DNS error. If, instead, you receive any response other than an error message (for example, you are redirected to another page), this could be the result of the following:
- A client-side application such as a browser plug-in is displaying an alternate page for a non-existent domain.
- Some ISPs may intercept and replace all NXDOMAIN responses with responses that lead to their own servers. If you are concerned that your ISP is intercepting Google Public DNS requests or responses, you should contact your ISP.
Will Google Public DNS be used to serve ads in the future?
No. We are committed to preserving the integrity of the DNS protocol. Google Public DNS will never return the address of an ad server for a non-existent domain.
What is DNS-over-HTTPS?
DNS resolution over an encrypted HTTPS connection. DNS-over-HTTPS greatly enhances privacy and security between a stub resolver and a recursive resolver, and complements DNSSEC to provide end-to-end authenticated DNS lookups.
Use and support
I am using another DNS service now. Can I also use Google Public DNS?
Yes. You can set Google Public DNS to be your primary or secondary DNS resolver, along with your current DNS resolver. Please remember that operating systems treat DNS resolvers differently: some will only use your primary DNS resolver and use the secondary in case the primary one fails, while others will round-robin among each of the resolvers.
Is Google Public DNS suitable for all types of Internet-enabled devices?
Yes. Google Public DNS can be used on any standards-compliant network device. If you find any situation where Google Public DNS does not work well, please let us know.
Can I run Google Public DNS on my office computer?
Some offices have private networks that allow you to access domains that you can't access outside of work. Using Google Public DNS might limit your access to these private domains. Please check your IT department's policy before using Google Public DNS on your office computer.
In which countries is Google Public DNS available?
It is available to Internet users around the world, though your experience may vary greatly based on your specific location.
Does Google Public DNS work with all ISPs?
Google Public DNS should work with most ISPs, assuming you have access to change your network DNS settings.
Do I need to use both Google Public DNS IP addresses?
No. You can use Google as your primary service by just using one of the IP addresses. However, be sure not to specify one address as both primary and secondary servers.
Does it matter in what order I specify the IP addresses?
No, the order does not matter. Either IP can be your primary or secondary name server.
What is the SLA for the service?
We are not providing an SLA for this service at this time.
I'm running an ISP. Can I redirect all my users to Google Public DNS?
Yes. But at this time, Google Public DNS is a service without an SLA. If you do want to use Google Public DNS, please open a rate limit request to discuss with us first. If you are below the QPS limits mentioned on that issue template, you can go ahead and start using Google Public DNS without contacting us.
How can I get support from the Google Public DNS team?
We recommend that you join our Google Groups to get useful updates from the team and ask any questions you have. If you are encountering a problem and would like to report it, please see Reporting issues for procedures.
How does Google Public DNS know where to send my queries?
Anycast routing directs your queries to the closest Google Public DNS server. For more information on anycast routing, see the Wikipedia entry.
Google Public DNS uses Name Server (NS) records published in the DNS root zone and zones of top-level domains to find the names and addresses of the DNS servers that are authoritative for any domain. Some of those name servers also use anycast routing.
Where are your servers currently located?
Google Public DNS servers are available worldwide. There are two answers to this question, one for clients and another for the DNS servers from which Google Public DNS gets the answers it returns to clients.
When clients send queries to Google Public DNS, they are routed to the nearest
location advertising the anycast address used (
188.8.131.52, or one of
the IPv6 addresses in
2001:4860:4860::). The specific locations advertising
these anycast addresses change due to network conditions and traffic load, and
include nearly all of the Core data centers and Edge Points of Presence (PoPs)
in the Google Edge Network.
Google Public DNS sends queries to authoritative servers from Core data centers and Google Cloud region locations. Google publishes a list of the IP address ranges Google Public DNS may use to query authoritative DNS servers (not all the ranges in the list are used). You can use it for geo-location of DNS queries lacking EDNS Client Subnet (ECS) data, and to configure ACLs to allow higher query rates from Google Public DNS.
In addition to this FAQ, Google also publishes the list as a DNS "TXT" record. Google updates both sources weekly with additions, modifications, and removals. Each IP address range entry includes the IATA code for the nearest airport. Automation for GeoIP data or ACLs should get this data via DNS, not by scraping this web page (see below for an example).
Locations of IP address ranges Google Public DNS uses to send queries
184.108.40.206/25 iad 220.127.116.11/26 syd 18.104.22.168/26 lhr 22.214.171.124/24 mrn 126.96.36.199/24 mrn 188.8.131.52/24 tpe 184.108.40.206/24 atl 220.127.116.11/24 mrn 18.104.22.168/24 tul 22.214.171.124/24 lpp 126.96.36.199/24 bru 188.8.131.52/24 cbf 184.108.40.206/24 bru 220.127.116.11/24 lpp 18.104.22.168/24 chs 22.214.171.124/24 cbf 126.96.36.199/24 chs 188.8.131.52/24 chs 184.108.40.206/24 lpp 220.127.116.11/24 dls 18.104.22.168/24 dub 22.214.171.124/24 mrn 126.96.36.199/24 lpp 188.8.131.52/24 cbf 184.108.40.206/24 tul 220.127.116.11/24 mrn 18.104.22.168/24 atl 22.214.171.124/24 atl 126.96.36.199/24 cbf 188.8.131.52/24 chs 184.108.40.206/24 bru 220.127.116.11/24 cbf 18.104.22.168/24 cbf 22.214.171.124/24 chs 126.96.36.199/24 chs 188.8.131.52/24 dls 184.108.40.206/24 dls 220.127.116.11/24 sin 18.104.22.168/24 tul 22.214.171.124/25 lhr 126.96.36.199/25 sin 188.8.131.52/25 syd 184.108.40.206/25 fra 220.127.116.11/26 fra 18.104.22.168/26 bom 22.214.171.124/25 bom 126.96.36.199/24 gru 188.8.131.52/24 atl 184.108.40.206/24 gru 220.127.116.11/24 bom 18.104.22.168/24 atl 22.214.171.124/24 grq 126.96.36.199/24 grq 188.8.131.52/24 tpe 184.108.40.206/24 yul 220.127.116.11/24 yul 18.104.22.168/24 yul 22.214.171.124/24 dls 126.96.36.199/24 sin 188.8.131.52/24 lax 184.108.40.206/24 lax 220.127.116.11/24 lax 18.104.22.168/24 nrt 22.214.171.124/24 hkg 126.96.36.199/24 hkg 188.8.131.52/24 hkg 184.108.40.206/24 chs 220.127.116.11/24 iad 18.104.22.168/24 iad 22.214.171.124/24 iad 126.96.36.199/24 zrh 188.8.131.52/24 zrh 184.108.40.206/24 kix 220.127.116.11/24 zrh 18.104.22.168/24 kix 22.214.171.124/24 cbf 126.96.36.199/24 kix 188.8.131.52/24 hhn 184.108.40.206/24 hhn 220.127.116.11/24 cbf 18.104.22.168/24 fra 22.214.171.124/24 hhn 126.96.36.199/24 fra 188.8.131.52/24 lhr 184.108.40.206/24 syd 220.127.116.11/24 icn 18.104.22.168/24 syd 22.214.171.124/24 icn 126.96.36.199/24 icn 188.8.131.52/24 ckv 184.108.40.206/24 iad 220.127.116.11/24 sin 18.104.22.168/24 tul 22.214.171.124/24 iad 126.96.36.199/24 iad 188.8.131.52/24 bru 184.108.40.206/24 chs 220.127.116.11/24 tul 18.104.22.168/24 uos 22.214.171.124/24 bom 126.96.36.199/24 cbf 188.8.131.52/24 scl 184.108.40.206/24 tpe 220.127.116.11/24 cbf 18.104.22.168/24 tul 22.214.171.124/24 dub 126.96.36.199/24 chs 188.8.131.52/24 lpp 184.108.40.206/24 tul 220.127.116.11/24 mrn 18.104.22.168/24 tul 22.214.171.124/24 atl 126.96.36.199/24 cbf 188.8.131.52/25 nrt 184.108.40.206/26 nrt 220.127.116.11/26 iad 18.104.22.168/24 grq 22.214.171.124/24 grq 126.96.36.199/24 tpe 2404:6800:4000::/48 bom 2404:6800:4003::/48 sin 2404:6800:4005::/48 hkg 2404:6800:4006::/48 syd 2404:6800:4008::/48 tpe 2404:6800:400a::/48 kix 2404:6800:400b::/48 nrt 2404:6800:4013::/48 icn 2607:f8b0:4001::/48 cbf 2607:f8b0:4002::/48 atl 2607:f8b0:4003::/48 tul 2607:f8b0:4004::/52 iad 2607:f8b0:4004:1000::/52 lax 2607:f8b0:400c::/48 chs 2607:f8b0:400d::/48 mrn 2607:f8b0:400e::/48 dls 2607:f8b0:4020::/48 yul 2607:f8b0:4023::/54 ckv 2607:f8b0:4023:400::/54 uos 2800:3f0:4001::/48 gru 2800:3f0:4003::/48 scl 2a00:1450:4001::/48 fra 2a00:1450:4009::/48 lhr 2a00:1450:400a::/48 zrh 2a00:1450:400b::/48 dub 2a00:1450:400c::/48 bru 2a00:1450:4010::/48 lpp 2a00:1450:4013::/48 grq 2a00:1450:4025::/48 hhn
Getting location data from DNS
An example shell script to get location data from DNS:
#!/bin/sh IFS="\"$IFS" LOCATIONS=locations.publicdns.goog. RESOLVER=publicdns.goog. for PROTO in tls tcp edns notcp; do for DIG in kdig dig; do $DIG "+$PROTO" +short . -t SOA @$RESOLVER 2>&- && break done $DIG "+$PROTO" +noall "$LOCATIONS" -t TXT "@$RESOLVER" 2>&- && break done for LOC in $($DIG "+$PROTO" +short "$LOCATIONS" -t TXT "@$RESOLVER") do case $LOC in '') : ;; *.*|*:*) printf '%s ' "$LOC" ;; *) printf '%s\n' "$LOC" ;; esac done
This script is an example that generates the same format as the list above; you can use any API that is capable of returning DNS TXT records and then parse the data it returns to get location information.
publicdns.goog zone is DNSSEC-signed and can be validated by any resolver.
If you can use DNS-over-TLS (supported by
kdig) to get the TXT records from a
DNSSEC validating resolver, it provides transport security even if you are not
validating DNSSEC, but for true security you should validate it yourself.
Is Google Public DNS based on open source software, such as BIND?
No. Google Public DNS is Google's own implementation of the DNS standards.
Does Google Public DNS comply with the DNS standards set forth by the IETF?
Are there plans to release Google Public DNS code as open source software?
At this time, there are no plans to open source Google Public DNS. But we have detailed all the steps we have taken to increase speed, security, and standards compliance.
Does Google Public DNS support IPv6?
Yes. Google Public DNS has IPv6 addresses for incoming requests from clients with IPv6 connectivity and responds to all requests for IPv6 addresses, returning AAAA records if they exist. We fully support IPv6-only authoritative name servers. The IPv6 resolver addresses are provided in the instructions for getting started with Google Public DNS.
Note that you may not see IPv6 results for Google web sites. To optimize the user experience, Google only serves AAAA records to clients with good IPv6 connectivity. This policy is completely independent of Google Public DNS, and is enforced by Google's authoritative name servers. For more information, please see the Google over IPv6 page.
For IPv6-only networks and systems, you can use Google Public DNS64 to get synthesized AAAA records for domain names with A records but no AAAA records. These synthesized AAAA records direct IPv6-only clients to a NAT64 gateway using a well-known IPv6 prefix reserved for NAT64 service. Just configure your systems following the getting started instructions, replacing the resolver addresses with the DNS64 IPv6 configuration.
Does Google Public DNS support the DNSSEC protocol?
Yes. Google Public DNS is a validating, security-aware resolver. All responses from DNSSEC signed zones are validated unless clients explicitly set the CD flag in DNS requests to disable the validation.
How can I find out if I am using DNSSEC?
You can do a simple test by visiting http://www.dnssec-failed.org/. This site has been specifically configured to return a DNS error due to a broken authentication chain. If you don't receive an error, you are not using DNSSEC.
How does Google Public DNS handle lookups which fail DNSSEC validation?
If Google Public DNS cannot validate a response (due to misconfiguration, missing or incorrect RRSIG records, etc.), it will return an error response (SERVFAIL) instead. However, if the impact is significant (e.g. a very popular domain is failing validation), we may temporarily disable validation on the zone until the problem is fixed.
How can I find out why a given domain fails DNSSEC validation?
Verisign Labs' DNS Analyzer and Sandia National Laboratories' DNSViz are two DNSSEC visualization tools that show the DNSSEC authentication chain for any domain. They show where breakages occur and are useful for looking up the source of DNSSEC failures.
Google Public DNS is serving old data. Can I force it to refresh its data?
Yes, you can use the Flush Cache tool to refresh the Google Public DNS cache for common record types and most domain names. You do not need to prove ownership of the domain to flush it, but you must solve a reCAPTCHA that restricts automated abuse of the service.
Flushing any record type for a domain that you have registered or sub-delegated
with NS records not only flushes cached responses for the type,
it also flushes delegation information about the name servers for that domain.
When you have recently changed name servers
(by changing registrars or DNS hosting providers)
it is critical to do this before flushing subdomains like
so they are not refreshed from stale data on your old DNS servers.
There are some limitations on what can be flushed:
Domains using EDNS Client Subnet (ECS) for geolocation cannot be flushed – for any domains using ECS, set TTLs for ECS-enabled records short enough (15 minutes or less) that you never need to flush them.
The only way to flush all subdomains, or all record types for a domain name, is to flush each record type for each domain name you want to flush. If this is not practical, you can always wait for the record TTLs to expire (these are generally limited to six hours even if the actual TTL is longer).
To flush internationalized domain names such as
пример.example, use the punycoded form (
xn‑‑e1afmkfd.examplefor the above example). Domains with characters other than ASCII letters, digits, hyphen, or underscore cannot be flushed.
Does Google Public DNS secure the so-called "last-hop" by encrypting communication with clients?
Yes! Traditional DNS traffic is transported over UDP or TCP without encryption. We also provide DNS-over-HTTPS which encrypts the traffic between clients and Google Public DNS. You may try it at: https://dns.google.com.
Why do we need DNS-over-HTTPS when we already have DNSSEC?
DNS-over-HTTPS and DNSSEC are complementary. Google Public DNS uses DNSSEC to authenticate responses from name servers whenever possible. However, in order to securely authenticate a traditional UDP or TCP response from Google Public DNS, a client would need to repeat the DNSSEC validation itself, which very few client resolvers currently do. DNS-over-HTTPS encrypts the traffic between stub resolvers and Google Public DNS, and complements DNSSEC to provide end-to-end authenticated DNS lookups.
I looked online and it seems that there are a lot of issues with open resolvers such as DDoS attacks, large-scale spoofing etc. Why did you make Google Public DNS an open resolver?
There are many articles online about some of the threats that open resolvers face. We made a conscious decision to be open and we have taken what we believe to be adequate precautions. See the security benefits page for information on the precautions we have taken to help protect our users from spoofing and cache poisoning, and to mitigate DNS-based DDoS attacks.
Are there tools that I can use to test the performance of Google Public DNS against that of other DNS services?
There are many freely available tools that you can use to measure Google Public DNS's response time. We recommend Namebench. Regardless of the tool you use, you should run the tool against a large number of domains—more than 5000—to ensure statistically significant results. Although the tests take longer to run, using a minimum of 5000 domains ensures that variability due to network latency (packet loss and retransmits) is minimized, and that Google Public DNS's large name cache is thoroughly exercised.
To set the number of domains in Namebench, use the Number of tests GUI
option or the
-t command line flag;
see the Namebench documentation for more information.
When I run
traceroute against the Google Public DNS resolvers, the response latency is higher than that of other services. Does this mean Google Public DNS is always slower?
No. In addition to the ping time, you also need to consider the average time to resolve a name. For example, if your ISP has a ping time of 20 ms, but a mean name resolution time of 500 ms, the overall average response time is 520 ms. If Google Public DNS has a ping time of 300 ms, but resolves many names in 1 ms, the overall average response time is 301 ms. To get a better comparison, we recommend that you test the name resolutions of a large set of domains.
I've read claims that Google Public DNS can slow down certain multimedia applications or websites. Are these true?
Many sites that provide downloadable or streaming multimedia host their content with DNS-based third-party content distribution networks (CDNs), such as Akamai. When a DNS resolver queries an authoritative name server for a CDN's IP address, the name server returns the closest (in network distance) address to the resolver, not the user. In some cases, for ISP-based resolvers as well as public resolvers such as Google Public DNS, the resolver may not be in close proximity to the users. In such cases, the browsing experience could be slowed down somewhat. Google Public DNS is no different from other DNS providers in this respect.
To help reduce the distance between DNS servers and users, Google Public DNS has deployed its servers all over the world. In particular, users in Europe should be directed to CDN content servers in Europe, users in Asia should be directed to CDN servers in Asia, and users in the eastern, central and western U.S. should be directed to CDN servers in those respective regions. We have also published this information to help CDNs provide good DNS results for multimedia users.
In addition, Google Public DNS uses a technical solution called EDNS Client Subnet as described in the RFC. This allows resolvers to pass in part of the client's IP address (the first 24/56 bits or less for IPv4/IPv6 respectively) as the source IP in the DNS message, so that name servers can return optimized results based on the user's location rather than that of the resolver.
What information does Google log when I use the Google Public DNS service?
Your client IP address is only logged temporarily (erased within a day or two), but information about ISPs and city/metro-level locations are kept longer for the purpose of making our service faster, better, and more secure.
Is any of the information collected stored with my Google account?
Does Google share the information it collects from the Google Public DNS service with anyone outside Google?
Does Google correlate or combine information from temporary or permanent logs with any personal information that I have provided Google for other services?