A Deeper Dive Into Public DNS Resolver Quad9 Thumbnail
Deploy360 6 July 2018

A Deeper Dive Into Public DNS Resolver Quad9

By Aftab SiddiquiSenior Manager, Internet Technology - Asia-Pacific

There are plenty of public DNS resolvers. The best known was Google Public DNS i.e. and for IPv4 and 2001:4860:4860::8888 and 2001:4860:4860::8844 for IPv6. But there are a few other options available now, each with different policies and technical features.

Two new Public DNS resolvers were recently launched. Quad9 (launched Nov 2017) and 1dot1dot1dot1 (launched Apr 2018). We have already covered in detail in a recent blog. So let’s talk about Quad9 (

IBM and Packet Clearing House (PCH) partnered with Global Cyber Alliance (GCA) to launch a Global Public Recursive DNS Resolver Service. Quad9 intends to protects users from accessing the overwhelming majority of malware, malicious domains, botnet infrastructure, and more. Leveraging threat intelligence from multiple industry leaders; it currently blocks up to two million threats per day.

A handy little infographic on the Quad9 website helps show how it works. Essentially, you set up Quad 9 as your DNS and when you query a known bad hostname, the DNS servers respond that the domain does not exist (NX DOMAIN or non-existent domain).

Quad 9 provides 2 types of resolvers, “Secure” which provides security features, and “Unsecured” which doesn’t.

Secure IPv4:
Secure IPv6: 2620:fe::fe

Unsecured IPv4:
Unsecured IPv6: 2620:fe::10

Threat Intelligence on malicious domains comes from 19 threat feeds. 12 partners are publicly listed and include IBM’s X-Force, 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 whitelisting 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.

As explained earlier, if the domain is on Quad9’s blacklist, the resolver answers with NXDOMAIN (No Such Domain – this domain does not exist). Let’s see an example of that:

Blacklisted Domain: renovation4all.gr
Source: openphish.com

In the first example, Google Public DNS ( returns an A record (, whereas in the second example Quad9 ( returns NXDOMAIN. Similarly, the “Unsecure” Quad9 ( returns the A record of the blacklisted domain. Same results for the IPv6.


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.

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.

DNS over TLS

A DNS query is by default sent over a plaintext connection, which makes them vulnerable to eavesdropping by attackers with access to the network channel, reducing the privacy of the person sending the DNS request. DNS over TLS (RFC7858) is a security protocol that forces all connections with DNS servers to be made securely using TLS. This effectively keeps any middle party (ISPs) from seeing what website you’re accessing. Initiation of DNS over TLS is very straightforward. By establishing a connection over a well-known port, clients and servers expect and agree to negotiate a TLS session to secure the channel.

RIPE Labs has published some extensive test results on this.

Final Word

Every step taken towards greater security, privacy, and reliability is a positive one. The addition of Quad9 and APNIC-Labs/CloudFlare’s is definitely going to bring good to the whole internet ecosystem.

Disclaimer: Viewpoints expressed in this post are those of the author and may or may not reflect official Internet Society positions.

Related articles

Improving Technical Security 15 March 2019

DNS Privacy Frequently Asked Questions (FAQ)

We previously posted about how the DNS does not inherently employ any mechanisms to provide confidentiality for DNS transactions,...

Improving Technical Security 14 March 2019

Introduction to DNS Privacy

Almost every time we use an Internet application, it starts with a DNS (Domain Name System) transaction to map...

Improving Technical Security 13 March 2019

IPv6 Security for IPv4 Engineers

It is often argued that IPv4 practices should be forgotten when deploying IPv6, as after all IPv6 is a...