With the advent of privacy there have been many services looking to "protect" your privacy, but are they really interested in doing so? In this research piece we are going to look at two popular DNS services CloudFlare and Quad9.

If you know what DNS is you can skip this part. Let's begin.

What is DNS?

Almost every activity on the Internet starts with a DNS query (and often several.) A key function of the DNS — Domain Name System — is to map human-readable names (e.g. example.com) to IP addresses that computers need in order to connect to each other. The DNS is, in essence, a phonebook for the Internet’s domain names. Those queries can reveal not only what websites an individual visits but also metadata about other services such as the domains of email contacts or chat services.

Let's look specifically into CloudFlare and Quad9 below.


Many users advocate the use of CloudFlare's privacy-speed DNS resolver as an alternative to Google, Dyn and many others because, well, it's focus on privacy and how quick it is compared to other DNS resolvers.

However, it does nothing for privacy and is mostly marketing hype, perhaps only to get more honey pot money? As for their DNS, they claim it's private due to encryption, but this is a double-edged sword. The encryption (in this scenario) protects you from malicious interceptions of the data as it travels from you to your DNS provider. It does not at all protect your DNS query from being read by the DNS provider, CloudFlare, in this instance.

What is CloudFlare?

CloudFlare is a CDN (content delivery network) which technically speaking is not an actual CDN, but more of a reverse proxy that takes over all of your traffic and then serves cached versions of your content whenever possible and from a nearby location while protecting websites against denial-of-service (DDoS) attacks. They offer a free plan with many appealing tools to manage your website. This sounds very interesting, especially for individuals or small companies which can't afford sophisticated infrastructure for their website(s). As the old saying goes, if the product is free, you are most likely the product.

However, in order to provide this service, they literally act as a MITM (man-in-the-middle,) even in SSL connections. When you fetch a page from a website that is served from CloudFlare, javascript has been injected on-the-fly into that page by CloudFlare, and they also plant a cookie that brands your browser with a globally-unique ID. This happens even if the website is using SSL and shows a cute little padlock in your browser. In fact, their entire approach to SSL appears to be a cynical marketing effort — it has a man-in-the-middle problem that cannot be resolved.

They market themselves as helping to improve internet security bringing SSL connections for all the websites which use their services. Your connection is encrypted, but only to CloudFlare's servers. After that, the connection to CloudFlare may simply be unencrypted, if the website operator chooses to do so. It may still be encrypted between CloudFlare's servers and website, but the contents remain visible to CloudFlare, even in the so-called full strict SSL. We don't know if CloudFlare is tracking you. We do know that they are perfectly positioned to immediately begin tracking web surfers who visit selected sites hosted by CloudFlare.

This allows them to learn your browsing habits and hinder your privacy. If you do access a website behind CloudFlare, avoid putting sensitive information on there, because all the contents are accessible to them. Even in their Keyless SSL which is used by some US banks, the contents of the pages are still accessible to them. And if you're just creating your own website, please, avoid them.

The history behind CloudFlare

In 2003, in an interview Matthew Prince talked about how the Department of Homeland Security got them started on the idea of CloudFlare:

Back in 2003, Lee Holloway and I started Project Honey Pot as an open-source project to track online fraud and abuse. The Project allowed anyone with a website to install a piece of code and track hackers and spammers.
We ran it as a hobby and didn't think much about it until, in 2008, the Department of Homeland Security called and said, "Do you have any idea how valuable the data you have is?" That started us thinking about how we could effectively deploy the data from Project Honey Pot, as well as other sources, in order to protect websites online. That turned into the initial impetus for CloudFlare.

— Matthew Prince, co-founder and CEO of Cloudflare, 2003 interview

BBC reporter Zoe Kleinman wrote that Matthew Prince wanted $20,000 for the Honey Pot data. "That check showed up so fast," said Prince. Michelle Zatlyn heard the story from Prince and replied, "If they'll pay for it, other people will pay for it." Soon she and Prince co-founded CloudFlare.

Another concerning issue is the auditing firm CloudFlare chose to have audit their product, KPMG, they are a "professional" service company and one of the Big Four auditors.

Cloudflare is working with third-party auditors at KPMG to examine their systems and guarantee they're not actually collecting your data.

CloudFlare has committed to retaining KPMG as their main and only auditor.

The Tor and CloudFlare debacle

Cloudflare's insistence on solving reCAPTCHA puzzles when visitors are coming from Tor exit nodes to one of the 2 million web sites that Cloudflare 'protects' can be very instrumental for traffic analysis and de-anonymizing of Tor users.

The only non-public prerequisite for the de-anonymizing entity is the ability to monitor traffic between ISPs and Tor entry nodes, and traffic entering CloudFlare servers (no decryption required in either case). There are, of course, no two million CloudFlare servers, probably there is no more than few hundred.

Each click on one of the images in the puzzle generates a total of about fifty packets between Tor user's computer and the CloudFlare's server (about half are requests and half are real-time responses from the server.) All this happens in less than a second, so eventual jitter introduced in onion mixing is immaterial. The packet group has predictable sizes and patterns, so all the adversary has to do is note the easily detectable signature of the "image click" event, and correlate it with the same on the CloudFlare side. Again, no decryption required.

There likely are many simultaneous users (thousands), but they do not solve puzzles at the same time, and they do not click on the puzzle image at the same time. Simple math shows that disambiguating is trivial. If there is some ambiguity left, CloudFlare can conveniently serve few more images to specific users (or even random users, as long as within the same few seconds different users get different amount of 'correct' images.)


Aside from CloudFlare's privacy policy which is awful the policy for its resolvers doesn't fair better. At most they try to present their FAQs "Commitment to privacy" as the "real" policy. Note: that they are not legally obligated to hold up their promises on their FAQs as it's not a legally contracting privacy policy between them and the end user.


Quad9 by IBM, PCH and GCA is the new DNS resolver on the block getting modest attention by providing content filtering, encryption protocols and promising not to log, store data, IPs of sites you visit etc.

But wait! It's largely funded by governments! Some founders/continuous funders include: the United States Secret Service, Manhattan District Attorney’s Office, City of London Police, France National Police and France Ministry of Justice: Division of Criminal Affairs & Pardon.

They are similar in how they operate to OpenDNS though they don't allow you to filter options manually and is taken care of automatically by them. The security features can be a bit too aggressive or lacking thereof.

They also utilize a malware-related domains block list based on the block list from IBM X-Force threat intelligence service and 18 other threat feeds. 11 partners are publicly listed and include Abuse.ch, Anti-Phishing Working Group (APWG), Bambenek Consulting, Cisco, F-Secure, mnemonic, Netlab, Payload Security, Proofpoint, RiskIQ, and ThreatSTOP. Seven remaining Threat Intelligence partners are not listed.

Quad9 also uses two white-listing methods. The first method uses a list of the top one million requested domains from the Majestic Million daily top one million feed. The feed is constantly updated, and the DNS accounts for any changes. The second is a “Gold List” of domains that should remain secure at all times e.g. Microsoft, Amazon, Google etc.


From a privacy point of view, Quad9 is specifically committed to protecting the users’ privacy and its service doesn’t retain request data. As mentioned in their FAQ: “When an entity or an individual is using the Quad9 infrastructure, their IP address is not logged in our system. We, however, log the geo-location of the system (city, state, country) and use this information for malicious campaign and actor analysis, as well as a component of the data we provide our threat intelligence partners.”

In the Quad9 Privacy policy they have clearly highlighted what data they are recording:

We do keep some generalized location information (at the city/metropolitan area level) so that we can conduct debugging and analyze abuse phenomena. We also use the collected information for the creation and sharing of telemetry (timestamp, geolocation, number of hits, first seen, last seen) for contributors, public publishing of general statistics of use of system (protections, threat types, counts, etc.) We do not correlate or combine information from our logs with any personal information that you have provided Quad9 for other services, or with your specific IP address.

There are exceptions to this storage model: In the event of events or observed behaviors which we deem malicious or anomalous, we may utilize more detailed logging to collect more specific IP address data in the process of normal network defense and mitigation. This collection and transmission off-site will be limited to IP addresses that we determine are involved in the event.

When you use Quad9 DNS Services, here is the full list of items that are included in logs:

  • Request domain name, e.g. example.net
  • Record type of requested domain, e.g. A, AAAA, NS, MX, TXT, etc.
  • Transport protocol on which the request arrived, i.e. TCP, UDP, and encryption status of the protocol
  • Origin IP general geolocation information: i.e. geocode, region ID, city ID, and metro code
  • Protocol version IP address – IPv4, or IPv6
  • Response code sent, e.g. SUCCESS, SERVFAIL, NXDOMAIN, etc.
  • Absolute arrival time
  • Name of the Quad9-operated machine that processed this request
  • Quad9 target IP to which this request was addressed (no relation to the user’s IP address)

It is also mentioned in the Privacy policy that Quad9 may keep the following data as summary information, including all the above EXCEPT for data about the DNS record requested:

  • Currently-advertised BGP-summarized IP prefix/netmask of apparent client origin
  • Autonomous system number (BGP ASN) of apparent client origin

All the above data may be kept in full or partial form in permanent archives.

Network Infrastructure

Quad9 is leveraging the Packet Clearing House (PCH) global assets around the world. PCH has Points of Presence (PoPs) in 181 internet Exchange Points all across the world.

Quad9 uses AS19281 to announce following IPv4 and IPv6 prefixes.

IPv6: 2620:fe::/48

No ROA found for any prefix.

What do I use then?

You should always have your DNS traffic encrypted! You can read more about that here; "Why You Should Encrypt Your DNS." Here you can see DNS encryption protocols along with more useful information.

Note: Remember encrypted or not the provider on the other end can still see your traffic, so you would need to trust the provider.

When it comes to a privacy-respecting DNS resolver, you're in luck there are plenty, even so you can host your own recursive server via Unbound or Dnsmasq (locally.)

If self-hosting isn't for you then check out our list of privacy-respecting DNS resolvers.


To summarize, we can't verify anything CloudFlare says, they are U.S. based, they hassle Tor/VPN users, the connection to their servers is sometimes unencrypted without any notice to the user - the SSL (and your green padlock) is to CloudFlare and not the destination.

With the abundance in viable solutions opposing CloudFlare and Quad 9 as mentioned above that are readily available along with self-hosting options. We see no need to use these aforementioned services from a technical and privacy stand point, for an individual or small business owner. With that said, you would need to trust both CloudFlare and Quad9, or any service for that matter inherently. Instead a more robust solution, one that is paid (self-hosted) and you are not the product will surely have a better privacy track record. In the end the choice will always be yours to make.


CloudFlare, We Have A Problem

CloudFlare Watch