▸ Data and Privacy Policy

The incorporation of Quad9 in Switzerland is complete. The responsible party for Quad9’s data and website privacy is Quad9, c/o SWITCH Werdstrasse 28004 Zürich. You can view relevant documents for Quad9 at the Commercial Register.
This policy document is intentionally written concisely. Expository discussion, beyond the scope of the policy itself, is provided in these sidebars.

0. Applicability of this Policy

This Privacy, Data Processing and Use Policy ("Policy") describes the policies of the Quad9 DNS Service (the "Service"), a recursive DNS resolver operated by the Quad9 Foundation ("Quad9"). This policy applies to Domain Name Service (DNS) transactions between Quad9's users and Quad9 under normal conditions.

This is version 1.0 of the Policy, published on Wednesday, February 17, 2021.

This policy is intended to meet or exceed the letter and spirit of Internet Engineering Task Force Request for Comment 8932, Recommendations for Privacy Service Operators, which is the applicable standard, and may be compared to Appendix 4.1, Example RPS Policy for reference.

We publish a closely related document, Compliance and Applicable Law, which we strongly recommend that you also read, as it documents the mechanisms by which we are held to account under criminal law for compliance with this privacy Policy, the remedies and legal protections available to you as a user of Quad9's services regardless of your country of citizenship or residency, and the limitations upon governmental power to encroach upon the protections we offer.

Quad9 may amend this policy by posting a new version, with an incremented version number, at https://quad9.net/privacy/policy/.

We have a separate privacy policy that applies under anomalous conditions, such as to users who are reasonably believed to be engaging in cyber attacks against or through us, and a separate policy that applies to communications with us via our website, email, or other channels.

1.0 Treatment of IP addresses

Quad9 regards Internet Protocol ("IP") addresses associated with its users to be Personally Identifiable Information ("PII"). Quad9 uses the union of the definitions of PII contained in Swiss law (Article 3 (a) FADP), United States law (2 CFR § 200.79) and European Union law (Article 4(1) GDPR), with the definition that extends the greatest protection to the user controlling in the event of any conflict between the three, and we extend that most stringent protection to all of Quad9's users, regardless of their citizenship or domicile.

In certain cases, the Internet Protocol (IP) address that your computer uses to communicate with Quad9 may constitute a form of Personally Identifiable Information (PII) to which Quad9 may be privy. Many nations classify and regulate IP addresses as PII, but this is not internationally harmonized.

When a user of the Service sends a query to Quad9, the query is transmitted across the Internet from an IP address under the control of, or in communication with, the user (the "Reply To Address"), to an IP address belonging to Quad9.

Quad9's own IP addresses (the addresses like 9.9.9.9, to which queries are addressed) are public and are associated with the Service rather than with any individual, so although they are IP addresses they do not constitute protected Personally Identifiable Information.

When Quad9 receives a DNS query, in very nearly every case, the IP address from which it receives the query is that of a caching/forwarding DNS resolver or the outside of a proxy or Network Address Translator ("NAT"); in any of these cases, the IP address represents a set of users, often quite a large set, sometimes numbering in the millions, and those users come and go, invisible to us, hidden behind that intermediary address. In these cases, which, to the best of our knowledge, make up nearly the entirety of the use of our systems, the IP address is not PII. But in an extraordinary case, the IP address from which we receive a query may be unique and globally routed and directly associated with an individual, in which case it is PII.

Quad9 makes no attempt to distinguish between IP addresses associated with resolvers or NATs versus those associated with individual users, because doing so would not improve our service but would simultaneously consume resources and needlessly single out individual users from the protective herd of our traffic. In short, although this practice is centrally important to those who would collect and monetize individuals' information ("cleaning the address list" in advertising terms), it is anathema to us.

Consequently, we take the simpler path of treating all IP addresses from which we receive queries as though they were PII. In this document, we refer to them all collectively as "Reply To Addresses" since that's their functional relationship to our service and our privacy policy, regardless of how (and invisibly to us) they may function from the user's perspective. This definition has utility in the context of a privacy policy because it encompasses all IP addresses from which we receive queries (of which we treat all as PII), but does not encompass our own (which are not).

When Quad9 receives the query, it is necessarily contained within an "envelope" (more precisely, an IP protocol header) that contains both of those addresses. Quad9 necessarily holds the Reply To Address in volatile random access memory ("RAM") for the few microseconds to milliseconds necessary to service the user's query. During this time, Quad9 uses the Reply To Address to increment a counter of the number of queries received from the enclosing BGP-advertised prefix of the Reply To Address and a counter of the number of queries received from a geographic region that is the smaller of a nation or a population of not less than 10,000 persons.

The Reply To Address is used for no other purposes, and is purged from RAM as soon as (in the case of a query the user delivers via User Datagram Protocol) we have transmitted the reply to the user's Reply To Address, or (in the case of a query the user delivers via the Transmission Control Protocol) the sooner of the user or Quad9 closing the TCP connection. The Reply To Address (or any representation of, or proxy for, it) is not copied to permanent storage, nor is it transmitted across the network to any destination other than the user. It leaves the machine on which we received it only in the form of a reply to the user – to no other destination, in no other form, for no other purpose.

We use server virtualization and we are aware that, in certain configurations we do not employ, it would be possible for the virtualization software to rely upon virtual memory. Specifically, if physical memory were to become insufficient, the "virtual memory" process would swap pages of RAM which were not in use to disk. If the machine were halted at exactly that moment, it is hypothetically possible that Reply To Addresses could be extracted from the memory pages that had been swapped to disk through brute-force decryption.

We do not believe that this process occurs on our servers for two reasons. First, we prevent this from occurring by allocating an amount of physical RAM to each client image that exceeds the amount of RAM it believes it has access to. Second, the pages of RAM that contain live DNS query transaction endpoints are the most active ones, not the least active, and if one were swapped to disk the function of the machine would essentially halt. This would stand out as a glaring beacon in our performance-monitoring systems, so if it were to occur it would be obvious to us – and it does not occur.

2.0 Data collection and sharing

As a public-benefit not-for-profit foundation dedicated to the provision of secure, private, and performant recursive DNS, Quad9 limits its data collection solely to data that enables it to better perform its mission in the service of its users. If data doesn't make the service more secure for its users, more private for its users, or faster and more resilient for its users, we don't bother to collect it.

Quad9 does not have any mechanism for users to "sign up" or create an account or otherwise disclose their identity to us, because we have no technical or business need to be able to identify users or distinguish one from another. Thus we do not have any records or data structures associated with or keyed by user, and consequently we do not have anywhere to put, or any way to retrieve, data about users.

2.1 IP addresses

Quad9 does not collect or record IP addresses, nor does it collect or hold any proxy for or representation of IP addresses, nor does it collect or hold any other unique identifier of individuals in lieu of IP addresses.

Because Quad9 does not collect or hold IP addresses, they cannot be combined or correlated with other information, such as query labels or timestamps, to violate the privacy of Quad9's users.

As stated above, Quad9 treats Reply To Addresses as personally identifiable information. The principal risk associated with PII is that it can be used in conjunction with other information to create a profile of an individual and their actions. An IP address by itself poses relatively little risk, and the other information that we have, such as the query label, also by itself poses little to no risk to a user's privacy. But if a user's IP address were to be associated with a query label, or a query label and a timestamp, the user's privacy would be forfeit. Therefore, Quad9's focus is on ensuring that IP addresses are never correlated with other information under our control. We accomplish this by minimizing our handling of IP addresses and ensuring that there is never a point in our process in which an IP address and a query label are associated, except in the answer provided to the user. Information that we do not have is information that cannot be sold, leaked, or stolen.

2.2 Data collected

Quad9's data collection is principally in the form of integer counters. At each Quad9 server, this is the full list of items we count:

  • The number of queries for each Query Type, e.g., A, AAAA, NS, MX, TXT
  • The number of each Response Type, e.g., SUCCESS, SERVFAIL, NXDOMAIN
  • The number of queries that arrive over each transport protocol and encryption type, e.g., IPv4, IPv6, TCP, UDP, DoT, DoH, DNScrypt
  • The number of queries originating in each geographic region
    • The number of queries for each malicious domain originating in each geocoded region
  • The number of queries originating in each BGP-advertised IP prefix
    • The number of queries for each malicious domain originating in each BGP-advertised IP prefix

In addition, we record:

  • The times of the first and most recent instances of queries for each query label
In order to forecast need and plan capacity, we keep counters of the numbers of queries we serve, what portion of them arrive at each of our servers, what portion of them come from each geographic area, what portion of them come from each carrier network, and what portion of them arrive via each of the protocols we support. We may also note the first and the most recent time we see a query for each unique query label. Also, in the case of query labels threat-intelligence analysts bring to our attention to block in order to protect our users from malware and fraud, we also count the number of times each malicious domain has been queried from each geographic region.

None of these counters contain any personally identifiable information, nor do they correlate with or specifically reference any individual query.

Where we perform counts per geographic region, we use demographic data to ensure that no region is smaller than the smaller of a nation or a population of not less than 10,000 persons.

For example, Nunavut is a territory of Canada with a population of 39,000, but no city within Nunavut has a population exceeding 8,000. Therefore, all queries originating in the territory are aggregated into a single counter representing more than 2,000,000 square kilometers. At the opposite extreme, Vatican City is a country with a population of 825 and an area of 0.4 square kilometers which, because it is an ISO 3166-recognized country, is also represented by a single counter. We distinguish between approximately 8,000 geographic regions that have an average population of 1,000,000 people each.

Our purpose in keeping geographic counters is twofold: to ensure that sufficient Quad9 server capacity exists within a region to serve its population locally and well; and, when cyber threats occur, to understand the degree to which they target or disproportionately affect any particular population. We recognize that if a geographic region were too small, or too sparsely populated, it could potentially contain only a single individual and could thus be correlated with PII from other sources to create a risk to that individual's privacy.

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

2.3 Sharing of data

Quad9 does not share, sell, or rent any information that could identify an individual.

We do not share this information because we do not have this information. We do not have this information because we do not need this information. Because we do not need this information, we have built no mechanism to collect, retain, analyze, or distribute it.

Quad9 shares very limited statistical counters with the threat intelligence analysts who provide the threat intelligence feeds that allow us to protect our users from malicious attacks. This feedback allows threat intelligence analysts to refine their analyses and provide us with more accurate information, which in turn allows us to provide our users with better security. This information does not include any personally identifiable information or anything that could be correlated with other data to identify an individual or their Internet use. Specifically, with each threat intelligence analyst, we share the following three pieces of information:

  • Timestamp of each query of each malicious domain they have identified to us
  • The number of queries for each malicious domain they have identified to us, originating in each geocoded region
  • The number of queries for each malicious domain they have identified to us, originating in each BGP-advertised IP prefix

As a convenience to the threat intelligence analysts, we also supply the originating Autonomous System Number associated with the BGP-advertised IP prefix. This is not data derived from users' queries but instead data derived independently from BGP routing tables. It does not contain PII, nor can it be combined with PII to characterize a user.

We do not share counters associated with malicious domains with threat intelligence analysts who have not identified that specific domain to us as malicious.

Quad9 provides data to a very few carefully vetted security researchers to help them better understand and better protect the public from cyber threats. This data may consist of a sparse statistical sampling of timestamped DNS responses from our cache or upstream authoritative servers, but no address, prefix, ASN, or other data related to the user or the query. It does not contain any PII or any data that we believe could be combined or correlated with PII to characterize a user or their behavior. When we provide such assistance, we do so only under a written agreement that the researcher use information we provide solely for the purpose of improving user security, and not for any other purposes. We require that researchers conduct their analysis on servers and infrastructure owned and operated by Quad9 and do not allow data to be exported from those systems in anything other than summary form.

Quad9 publishes general information, such as number of threats blocked and infrastructure uptime, to the public.

3.0 Exceptions

Like any operator of critical infrastructure, we must maintain the security of our systems in order to ensure the privacy of our users. We have a separate privacy policy for anomalous conditions, such as any in which users are engaging in cyber attacks against us.

4.0 Associated entities

Quad9 supplies data to the threat intelligence analysts who provide us with the means to protect our users from malicious domains, as detailed in Section 2.3. Quad9 provides information to researchers to help them better understand and better protect the public from cyber threats, but such assistance as we offer does not contain any PII or data that we believe could be combined or correlated with PII to characterize a user or their behavior. When we provide such assistance, we do so only under a written agreement that the researcher use information we provide solely for the purpose of improving user security, and not for any other purposes. No other entities receive data from Quad9, other than that made available to the public at large.

5.0 Correlation of data

We do not correlate or combine data in our possession with data from other sources.

6.0 Result filtering

Quad9 provides both filtered and unfiltered responses to DNS queries, at the user's sole option.

6.1 Filtering

Quad9 uses threat intelligence information derived from qualified threat intelligence analysts to provide optional security protection to Quad9's users. Quad9 vets threat intelligence analysts carefully and assesses the quality of the intelligence provided on a continuous basis. Threat intelligence is aggregated from these many sources into a single "block list" of domains believed with a high degree of confidence to exist principally or exclusively for the purpose of harming a user. With the acknowledgment that many of these data feeds consist of millions of malicious entities and are thus not subject to individual human review or scrutiny, Quad9 engages in continuous best-effort review of these data feeds to ensure quality and fitness-for-purpose. Quad9 engages bidirectionally with threat intelligence analysts to help them refine the quality of their analysis, and thus the degree of protection it affords Quad9's users. This engagement includes the sharing of data as defined in section 2.3.

Quad9 also allows users to query the current blocking status of any domain via a form on our web site. For every blocked domain, Quad9 discloses the identity of the threat analyst that suggested the block and provides any explanatory text they may have provided, via this mechanism.

6.1.1 Censorship

Quad9 does not censor the answers it provides for any purpose other than the blocking of malicious domains associated with phishing, malware, vulnerability exploit, or fraud, as detailed in section 6.1. Quad9 does not accept censorship requests from governments or other entities. Quad9 specifies to its threat intelligence analysts that it does not accept domain-blocking suggestions for reasons of censorship and will reverse any such attempts we become aware of.

6.1.2 Accidental blocking

Quad9 accepts "false positive" reports from the public regarding domains users believe to be legitimate and erroneously blocked. These reports may be submitted through a form on our website or via email to support@quad9.net. Quad9 makes a best-effort attempt to investigate each reported domain manually. Users should bear in mind that malicious actors essentially always report their malicious domains to us as being erroneously blocked, so validating false positives is a laborious process. Upon determining that a blocked domain has been blocked erroneously, Quad9 adds it to an "allow list" that overrides the malicious threat intelligence we receive from threat intelligence analysts, and the domain is permanently removed from our aggregate block list.

7.0 Your rights

You have the right to receive information about your personal data processed by us in writing and free of charge at any time. You also have the right to correct, delete and limit the processing of data, as well as the release of certain personal data for transfer to another controller. Insofar as processing is based on your consent, you have the right to withdraw this consent with effect for the future. You will find the relevant contact details in the introduction to this privacy statement.

In addition, every data subject has the right to enforce his/her rights in court or to lodge a complaint with the competent data protection authority. The competent data protection authority of Switzerland is the Federal Data Protection and Information Commissioner (http://www.edoeb.admin.ch).

8.0 Contact

If you have any privacy-related questions or comments related to this Statement, please send an email to support@quad9.net. You can also contact us by writing to this address:

Quad9, c/o SWITCH, Werdstrasse 2, P.O. Box, CH-2021 Zurich

-end-

This Policy is published under a Creative Commons Attribution-NonCommercial-ShareAlike license.



External links
Request for Comment 8932 - Recommendations for Privacy Service Operators
Example RPS Policy
Article 3 (a) FADP - Swiss Federal Act on Data Protection
2 CFR § 200.79 - United States law
Article 4(1) GDPR - European Union regulations
Caching/forwarding DNS resolver - Quora
Proxy server - Wikipedia
Network Address Translator - Wikipedia