Public DNS Server List

Google IP address ranges

Recently I decided to try the Google Compute Engine Cloud, and one of the things I liked right from the beginning was the ability to connect via SSH to your Ubuntu box. I am going to have to read a bit more about it but basically it seems like it generates a keypair, sets it up on your server and then opens a terminal connection via ssh on your web browser… how cool is that?! In my case I wanted to increase the security by limiting the IP addresses that can access the SSH port. Here is where this post comes along. If you look at the documentation basically it says you need to allow all Google IP addresses because the web client may connect from any Google IP… I know, a lot of IPs to authorize but I guess it is better than opening the port to all IP addresses in the world. I am probably going to enable and disable the rule manually but open it to all Google IP addresses for convenience of using the web client to initiate an ssh connection.

The ranges

Well, the IP ranges that Google owns/manages vary throughout time. Fortunately, there are ways to obtain the lates versions at any given point. Unfortunately, I am not sure how can you dynamically update them in the Google Cloud Engine’s firewall rules so I am manually adding them. In order to identify them I am relying on the spf record google offers: _spf.google.com

Here is the information I’ve found at the time of writting:

v=spf1 include:_netblocks.google.com include:_netblocks2.google.com include:_netblocks3.google.com ~all

v=spf1 ip4:64.18.0.0/20 ip4:64.233.160.0/19 ip4:66.102.0.0/20 ip4:66.249.80.0/20 ip4:72.14.192.0/18 ip4:74.125.0.0/16 ip4:108.177.8.0/21 ip4:173.194.0.0/16 ip4:207.126.144.0/20 ip4:209.85.128.0/17 ip4:216.58.192.0/19 ip4:216.239.32.0/19 ~all

v=spf1 ip6:2001:4860:4000::/36 ip6:2404:6800:4000::/36 ip6:2607:f8b0:4000::/36 ip6:2800:3f0:4000::/36 ip6:2a00:1450:4000::/36 ip6:2c0f:fb50:4000::/36 ~all

v=spf1 ip4:172.217.0.0/19 ~all

So there you have it. The first block is called netblocks which contains all the blocks in the IPv4 space, then you have netblocks2 which contains all the blocks in the IPv6 space… which leaves netblocks3 which contains an IPv4 address range but I am not sure why not simply include it in netblocks. If anyone knows the reason or has a good guess please share!

If you wish to query this information anytime yourself, you can do it querying the Google DNS servers like so:

So it is possible to automate the update of the ranges via a shell script for example… or an API call… but for me I think it is not necessary seeing updates shouldn’t happen too often and if there is an issue I can always update as required.

Implementing basic validity checking

Some DNS cache corruption can be due to unintentional, and not necessarily
malicious, mismatches between requests and responses (e.g. perhaps because of a
misconfigured name server, a bug in the DNS software, and so on).
At a minimum, DNS resolvers should put in checks to verify the credibility and
relevance of name servers’ responses.
We recommend (and implement) all of the following defenses:

• Do not set the recursive bit in outgoing requests, and always follow
  delegation chains explicitly.
  Disabling the recursive bit ensures that your resolver operates in
  «iterative» mode so that you query each name server in the delegation chain
  explicitly, rather than allowing another name server to perform these
  queries on your behalf.
• Reject suspicious response messages.
  See below for details of what we consider to be «suspicious».
• Do not return A records to clients based on glue records cached from
  previous requests.
  For example, if you receive a client query for ns1.example.com, you should
  re-resolve the address, rather than sending an A record based on cached glue
  records returned from a .com TLD name server.

Rejecting responses that do not meet required criteria

Google Public DNS rejects all of the following:

• Unparseable or malformed responses.
• Responses in which the query ID, source IP, source port, or query name do
  not match those of the request.
• Records which are not relevant to the request.
• Answer records for which we cannot reconstruct the CNAME chain.
• Records (in the answer, authority, or additional sections) for which the
  responding name server is not credible.
  We determine the «credibility» of a name server by its place in the
  delegation chain for a given domain.
  Google Public DNS caches delegation chain information, and we verify each
  incoming response against the cached information to determine the responding
  name server’s credibility for responding to a particular request.

Serviceedit

Google Public DNS operates recursive name servers for public use at the IP addresses 8.8.8.8 and 8.8.4.4 for IPv4, and 2001:4860:4860::8888 and 2001:4860:4860::8844, for IPv6. The addresses are mapped to the nearest operational server by anycast routing.

The service does not use conventional DNS name server software, such as BIND, instead relying on a custom-designed implementation, conforming to the DNS standards set forth by the IETF. It fully supports the DNSSEC protocol since 19 March 2013. Previously, Google Public DNS accepted and forwarded DNSSEC-formatted messages but did not perform validation.

Some DNS providers practice DNS hijacking while processing queries, redirecting web browsers to an advertisement site operated by the provider when a nonexistent domain name is queried. This is considered intentional breaking of the DNS specification. The Google service correctly replies with a non-existent domain (NXDOMAIN) response.

The Google service also addresses DNS security. A common attack vector is to interfere with a DNS service to achieve redirection of web pages from legitimate to malicious servers. Google documents efforts to be resistant to DNS cache poisoning, including as well as denial-of-service attacks.

Google claims various efficiency and speed benefits, such as using anycast routing to send user requests to the closest data center, over-provisioning servers to handle denial-of-service attacks and load balancing servers using two cache levels with a small per-host cache containing the most popular names and another pool of servers partitioned by the name to be looked up. This second level cache reduces the fragmentation and cache miss rate that can result from increasing the number of servers.

DNS servers in China

This list of public and free DNS servers is
checked
continuously.
Read how to
change your DNS server settings
.

Diese Seite anzeigen auf
deutsch

|
Changelog
|
Impressum
|
Data Privacy
|
bithopper (at) jabber.ccc.de
|
Powered by
Ruby On Rails

Privacyedit

Google stated that for the purposes of performance and security, the querying IP address will be deleted after 24–48 hours, but Internet service provider (ISP) and location information are stored permanently on their servers.

According to Google’s general privacy policy, «We may combine personal information from one service with information, including personal information, from other Google services». However, Google Public DNS’s policy specifically states that «We don’t correlate or combine information from our temporary or permanent logs with any personal information that you have provided Google for other services.»

OpenNIC

IP Addresses: 206.125.173.29 and 45.32.230.225

The OpenNIC project is most well-known for its user owned and controlled top-level Network Information Center. It offers an alternative to typical top-level domain (TLD) registries such as ICANN

How the Internet Works

How the Internet Works
We can now access the Internet from our home computers, office, laptops and our phones. But many people still aren’t entirely sure what the Internet is and how it really works.
Read More

.

However, the firm also provides free DNS servers. There are four servers to choose from. I’ve given you the two with the best uptime above (100 percent and 99.95 percent, respectively).

Once again, there are some key pillars of its security features you need to be aware of. Like DNS Watch, it offers DNS neutrality and prevention of ISP DNS hijacking, but it also provides a couple of additional features.

First, you get to choose how much data logging is done by OpenNIC. It gives you an unprecedented level of granular control.

Second, and perhaps more impressive, you also get to vote in how OpenNIC operates. You can have your say in everything from deciding new TLDs to project-wide policy changes. If something happens you don’t like, you can make sure you let OpenNIC know about it!

Which DNS Servers Do You Use for Security and Privacy

In this article, I’ve introduced you to five of the best DNS servers for protecting your security and privacy.

Which is the best? It’s hard to say. Much depends on your personal priorities. If parental controls are your primary concern, turn to OpenDNS. If you want to improve your speed at the expense of some non-personal data logging, use Google. Want to be as discreet as possible but potentially sacrifice some speed and uptime? Consider one of the latter three options.

Remember, using a secure DNS server is important to protect yourself from DNS cache poisoning

What Is DNS Cache Poisoning? How DNS Spoofing Can Hijack You

What Is DNS Cache Poisoning? How DNS Spoofing Can Hijack You
Your router, PC, and even your ISP’s servers can be subverted by DNS cache poisoning (or spoofing). Here’s how to avoid that.
Read More

. And you can also take a look at how Cloudfare DNS helps solve privacy risks

How Cloudflare DNS Helps Solve 4 Big DNS Privacy Risks

How Cloudflare DNS Helps Solve 4 Big DNS Privacy Risks
Cloudflare has released a free new security tool. Here’s how Cloudflare DNS helps improves security, privacy, and even speed.
Read More

.

History

In December 2009, Google Public DNS was launched with its announcement on the Official Google Blog by product manager Prem Ramaswami, with an additional post on the Google Code blog.

In January 2019, Google DNS adopted the DNS over TLS protocol.

DNSSEC

At the launch of Google Public DNS, it did not directly support DNSSEC. Although RRSIG records could be queried, the AD (Authenticated Data) flag was not set in the launch version, meaning the server was unable to validate signatures for all of the data. This was upgraded on 28 January 2013, when Google’s DNS servers silently started providing DNSSEC validation information, but only if the client explicitly set the DNSSEC OK (DO) flag on its query. This service requiring a client-side flag was replaced on 6 May 2013 with full DNSSEC validation by default, meaning all queries will be validated unless clients explicitly opt out.

Client subnet

Since June 2014, Google Public DNS automatically detects nameservers that support EDNS Client Subnet (ECS) options as defined in the IETF draft (by probing name servers at a low rate with ECS queries and caching the ECS capability), and will send queries with ECS options to such name servers automatically.

Censorship in Turkey

In March 2014, use of Google Public DNS was blocked in Turkey after it was used to circumvent the blocking of , which took effect on 20 March 2014 under court order. The block was the result of earlier remarks by Prime Minister Tayyip Erdogan who vowed to «wipe out Twitter» following damaging allegations of corruption in his inner circle. The method became popular after it was determined that a simple domain name block was used to enforce the ban, which would easily be bypassed by using an alternate DNS system. Activists distributed information on how to use the service, and spray-painted the IP addresses used by the service as graffiti on buildings. Following the discovery of this method, the government moved to directly block Twitter’s IP address, and Google Public DNS was blocked entirely.

Подробное описание

C 25 мая 2010 года система Analytics поддерживает функцию в ga.js (и с недавних пор в analytics.js), которая позволяет владельцам сайтов скрывать IP-адреса своих посетителей при обработке данных в нашей системе. Анонимизация и частичное хранение IP-адресов помогают выполнять требования по защите личных данных, включая как политики конфиденциальности самих ресурсов, так и государственные законы. Адрес маскируется сразу же, как только поступает в сеть сбора данных Analytics, до обработки и хранения.

Анонимизация IP-адресов в Analytics выполняется в два этапа: на уровне тегов JavaScript и сети сбора данных. Ниже эта процедура описана подробнее.

JavaScript-тег Analytics

Когда браузер, в котором включена поддержка JavaScript, загружает страницу с тегом Analytics (ga.js или analytics.js), асинхронно происходят два действия: загружается для обработки очередь функций и запрашивается JavaScript-код. Очередь функций – это массив JavaScript, в который принудительно передаются различные функции сбора данных и настройки Analytics. К таким функциям, которые задаются владельцем сайта при внедрении Analytics, могут относиться указание номера аккаунта и отправка информации о просмотрах страниц в сеть сбора данных Analytics.

Когда JavaScript-код Analytics выполняет функцию из этой очереди, активируется отправка данных в сеть сбора Analytics (обычно это функция ga(‘send’, ‘pageview’) в JavaScript-библиотеке analytics.js и в библиотеке ga.js). Данные передаются как параметры URL, добавленные к HTTP-запросу http://www.google-analytics.com/_utm.gif (для ga.js) и http://www.google-analytics.com/collect (для analytics.js). Если функция анонимизации была вызвана до функции отслеживания страницы, то к запросу пикселя прикрепляется дополнительный параметр анонимизации IP-адреса (&aip=1).

Сеть сбора данных Analytics

В сеть сбора данных Analytics объединены серверы, которые выполняют две основные задачи: обслуживают ga.js и analytics.js (JavaScript-коды Analytics) и собирают данные, которые передаются в запросах _utm.gif и /collect.

Поступающий запрос файла ga.js, analytics.js, _utm.gif или /collect содержит дополнительную информацию в заголовке HTTP-запроса (например, используемый браузер) и в заголовке TCP/IP (например, IP-адрес источника запроса).

Как только запрос _utm.gif поступает в систему, он передается в память для анонимизации. Если его URL содержит параметр &aip=1 (который добавляется JavaScript-кодом Analytics после обработки функции анонимизации в или ), то последний октет IP-адреса посетителя обнуляется прямо в памяти. Например, значение 12.214.31.144 меняется на 12.214.31.0 (для IPv6-адресов обнуляются последние 80 из 128 бит). Только после такой анонимизации запрос записывается на диск для обработки. Фактически при использовании функции маскировки полный адрес никогда не хранится в системе, а обнуление его части происходит в памяти сразу же после получения запроса.

DNS Watch

IP Addresses: 84.200.69.80 and 84.200.70.40

DNS Watch is a hugely security conscious DNS provider. It’s entirely free for all users and doesn’t offer tiered packages like OpenDNS.

Its security offering can be broken down into four key areas:

DNS Neutrality — The servers do not censor any DNS requests. This differs to some ISPs around the world who actively censor what you can and cannot access.

Privacy Protection — The company does not log any DNS queries. It is not recording any of your actions. To once again draw a comparison with a typical ISP DNS server, many log your history, and some don’t even anonymize the data collected.

Data for Sale — The company does not have any business deals in place with ad networks or other institutions that have an interest in learning about your online habits.

No ISP DNS Hijacking — If you use your ISP’s DNS servers, no doubt you’ll have occasionally stumbled across a sponsored search page if the site you’re trying to visit does not return a response. They’re a nightmare for privacy; anything you enter on those pages is collected and collated by your ISP. DNS Watch doesn’t do this. You’ll just see your standard browser page if your request is unsuccessful.

Google Public DNS

IP Addresses: 8.8.8.8 and 8.8.4.4

I’m going to start my list with two of the most well-known third-party servers. First up, Google Public DNS.

Google’s DNS most significant advantage is its speed. DNS lookups often cause a bottleneck that can slow down your browsing. According to Google’s research, the biggest cause of the bottlenecks are “cache misses.” They occur when a DNS resolver has to communicate with several external name servers to load a page.

Google tries to mitigate the problem by offering three key performance features:

• Global coverage — There are servers nearby regardless of where you are in the world.
• Denial-of-Service (DoS) attack prevention — Google provides DNSSEC security as standard.
• Load balancing — Shared caching improves the cache hit rate.

Although Google offers DNSSEC and DNS-over-HTTPS as standard, there is one significant security drawback to using the service: data collection

6 Surprising Ways Your Data Is Being Collected

6 Surprising Ways Your Data Is Being Collected
You know that your data is being collected, mainly by your ISP and the surveillance apparatus of the NSA and GCHQ. But who else is mining cash out of your privacy?
Read More

. Remember, Google is an advertising company, and user data is its biggest asset. Although the DNS data it collects is theoretically impersonal, it might scare away some privacy-conscious users.

Rate-limiting queries

Preventing denial-of-service attacks poses several particular challenges for
open recursive DNS resolvers:

• Open recursive resolvers are attractive targets for launching amplification
  attacks.
  They are high-capacity, high-reliability servers and can produce larger
  responses than a typical authoritative name server—especially if an
  attacker can inject a large response into their cache.
  It is incumbent on any developer of an open DNS service to prevent their
  servers from being used to launch attacks on other systems.
• Amplification attacks can be difficult to detect while they are occurring.
  Attackers can launch an attack via thousands of open resolvers, so that each
  resolver only sees a small fraction of the overall query volume and cannot
  extract a clear signal that it has been compromised.
• Malicious traffic must be blocked without any disruption or degration of the
  DNS service to normal users.
  DNS is an essential network service, so shutting down servers to cut off an
  attack is not an option, nor is denying service to any given client IP for
  too long.
  Resolvers must be able to quickly block an attack as soon as it starts,
  and restore fully operational service as soon as the attack ends.

The best approach for combating DoS attacks is to impose a rate-limiting or
«throttling» mechanism.
Google Public DNS implements two kinds of rate control:

• Rate control of outgoing requests to other name servers.
  To protect other DNS name servers against DoS attacks that could be launched
  from our resolver servers, Google Public DNS enforces QPS
  limits on outgoing requests from each serving cluster for each name server
  IP address.

• Rate control of outgoing responses to clients.
  To protect any other systems against amplification and traditional
  distributed DoS (botnet) attacks that could be launched from our resolver
  servers, Google Public DNS performs two types of rate limiting on client
  queries:

  • To protect against traditional volume-based attacks, each server imposes
    per-client-IP QPS and average bandwidth limits.
  • To guard against amplification attacks, in which large responses to
    small queries are exploited, each server enforces a per-client-IP
    maximum average amplification factor.
    The average amplification factor is a configurable ratio of
    response-to-query size, determined from historical traffic patterns
    observed in our server logs.

  If DNS queries from one source IP address exceed the maximum QPS rate,
  excess queries will be dropped.
  If DNS queries over UDP from one source IP address exceed
  the average bandwidth or amplification limit consistently
  (the occasional large response will pass),
  queries may be dropped or only a small response may be sent.
  Small responses may be an error response or
  an empty response with the truncation bit set
  (so that most legitimate queries will be retried via TCP and succeed).
  Not all systems or programs will retry via TCP,
  and DNS over TCP may be blocked by firewalls on the client side,
  so some applications may not operate correctly when replies are truncated.
  Nonetheless, truncation allows RFC-compliant clients to work properly in
  most cases.

Privacy

Google stated that for the purposes of performance and security, the querying IP address will be deleted after 24–48 hours, but Internet service provider (ISP) and location information are stored permanently on their servers.

According to Google’s general privacy policy, «We may combine personal information from one service with information, including personal information, from other Google services». However, Google Public DNS’s policy specifically states that «We don’t correlate or combine information from our temporary or permanent logs with any personal information that you have provided Google for other services.»

Service

Google Public DNS operates recursive name servers for public use at the IP addresses 8.8.8.8 and 8.8.4.4 for IPv4, and 2001:4860:4860::8888 and 2001:4860:4860::8844, for IPv6. The addresses are mapped to the nearest operational server by anycast routing.

The service does not use conventional DNS name server software, such as BIND, instead relying on a custom-designed implementation, conforming to the DNS standards set forth by the IETF. It fully supports the DNSSEC protocol since 19 March 2013. Previously, Google Public DNS accepted and forwarded DNSSEC-formatted messages but did not perform validation.

Some DNS providers practice DNS hijacking while processing queries, redirecting web browsers to an advertisement site operated by the provider when a nonexistent domain name is queried. This is considered intentional breaking of the DNS specification. The Google service correctly replies with a non-existent domain (NXDOMAIN) response.

The Google service also addresses DNS security. A common attack vector is to interfere with a DNS service to achieve redirection of web pages from legitimate to malicious servers. Google documents efforts to be resistant to DNS cache poisoning, including as well as denial-of-service attacks.

Google claims various efficiency and speed benefits, such as using anycast routing to send user requests to the closest data center, over-provisioning servers to handle denial-of-service attacks and load balancing servers using two cache levels with a small per-host cache containing the most popular names and another pool of servers partitioned by the name to be looked up. This second level cache reduces the fragmentation and cache miss rate that can result from increasing the number of servers.

DNSSEC

The Domain Name Security Extensions (DNSSEC) standard is specified in several
IETF RFCs:
, , , and .

Resolvers that implement DNSSEC counter cache poisoning attacks by verifying the
authenticity of responses received from name servers.
Each DNS zone maintains a set of private/public key pairs and for each DNS
record, a unique digital signature is generated and encrypted using the private
key.
The corresponding public key is then authenticated via a chain of trust by keys
belonging to parent zones.
DNSSEC-compliant resolvers reject reponses that do not contain the correct
signatures.
DNSSEC effectively prevents responses from being tampered with, because in
practice, signatures are almost impossible to forge without access to private
keys.

As of January 2013, Google Public DNS fully supports DNSSEC.
We accept and forward DNSSEC-formatted messages and validate responses for
correct authentication.
We strongly encourage other resolvers to do the same.

Recently checked

This list of public and free DNS servers is
checked
continuously.
Read how to
change your DNS server settings
.

When you cant reach Google the regular way

Mizter_x94 / pixabay

Internet & Network

• Guides & Tutorials

• The Wireless Connection

• Basics

• Installing & Upgrading

• Tips & Tricks

• Key Concepts

• What Are Bitcoins?

by
Bradley Mitchell

An MIT graduate who brings years of technical experience to articles on SEO, computers, and wireless networking.

Updated November 19, 2018

As one of the world’s largest internet companies, Google occupies a sizable amount of public IP address space. The many different Google IP addresses support searches and other internet services such as the company’s DNS servers.

There are reasons you might want to find the IP address of Google’s website. 

Why You Might Want Google’s IP Address

If all is working normally, you can visit the Google search engine at Google.com. However, it’s also possible to reach it using one of Google’s IP addresses, even when the domain can’t be reached by name.

If there’s an issue with DNS, and Google’s IP address can’t be found by entering «google.com,» you can instead enter the URL as a valid IP address in the form http://74.125.224.72/. Some IP addresses work better than others depending on your locale.

Testing connections to websites by addresses instead of names can be a helpful troubleshooting step to verify whether the connection has an issue with name resolution rather than some other kind of technical glitch.

Also, website administrators are often curious to know when Google web crawlers visit their sites. Analyzing web server logs reveals the IP addresses of crawlers but not their domains.

Google.com IP Address Ranges

Google uses the following public IP address ranges:

• 64.233.160.0 – 64.233.191.255 
• 66.102.0.0 – 66.102.15.255
• 66.249.64.0 – 66.249.95.255
• 72.14.192.0 – 72.14.255.255
• 74.125.0.0 – 74.125.255.255
• 209.85.128.0 – 209.85.255.255
• 216.239.32.0 – 216.239.63.255

Only certain addresses from Google’s pool work at any given time depending on how Google chooses to deploy its web server network, which is why a random example above one of these ranges may or may not work for you at a specific time. When you find an IP address that works for you, make a note of it for future use.

Google DNS IP Addresses

Google maintains the IP addresses 8.8.8.8 and 8.8.4.4 as the primary and secondary DNS addresses for Google Public DNS. A network of DNS servers strategically located around the world support queries at these addresses.

Googlebot IP Addresses

Besides serving Google.com, some of Google’s IP addresses are used by its Googlebot web crawlers.

Website administrators like to monitor when Google’s crawler visits their domains. Google does not publish an official list of Googlebot IP addresses but instead recommends users follow these instructions for verifying Googlebot addresses.

Many of the active addresses can be captured from lookups:

• 64.68.90.1 – 64.68.90.255
• 64.233.173.193 – 64.233.173.255
• 66.249.64.1 – 66.249.79.255
• 216.239.33.96 – 216.239.59.128

This is not a complete list, and the specific addresses used by Googlebot can change at any time without notice.

Continue Reading

OpenDNS

IP Addresses: 208.67.220.220 and 208.67.222.222

The other most commonly-cited third-party DNS provider is OpenDNS. Since November 2016, the service has been owned by Cisco.

Users can choose from three tiers of service: OpenDNS Family Shield, OpenDNS Home, and OpenDNS VIP Home.

The first two services — OpenDNS Family Shield and OpenDNS Home — are both free. The features are largely the same; they both have built-in identity theft protection and parental controls for every device in your home. The only significant difference is customizable filtering: the Family Shield is pre-configured, the Home package needs your input.

The VIP Home package costs $19.95 per year. It introduces detailed internet usage stats for the previous 12 months (categorized across eight types of security threats

5 Online Security Threats That You Need to Tell Your Friends About

5 Online Security Threats That You Need to Tell Your Friends About
You’d be surprised to discover where all malware is lingering today. It’s no longer just average computers, but more likely anything with some sort of connected device, including toys.
Read More

and 60 types of web content) and the ability to restrict internet access to a whitelist of domains, thus giving users on your network a “locked down” experience. The company also offers business packages.

Sadly, there is a trade-off for some of these services. The company stores both your DNS and IP address information, and places web beacons on pages you visit using the servers so it can learn about “what content is effective.”

You can draw your own conclusions about that quote.