Data and Privacy Policy

The responsible party for Quad9’s data and website privacy is the Swiss foundation Quad9, c/o SWITCH, Werdstrasse 2, 8004 Zürich. You can view relevant documents at the Commercial Register.

This policy document is intentionally written concisely. Expository discussion, beyond the scope of the policy itself, is provided in these callout boxes with shaded text.

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.1 of the Policy, published on June 24, 2026.

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 D. Example RPS D.1 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 (see section 3.0), 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 or other anycast/unicast addresses to which queries are addressed, and unicast IP addresses associated with Quad9 equipment which generate outbound queries to authoritative servers) 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. Query activity by Quad9’s own IP addresses towards authoritative servers is not considered PII or private. Quad9 will attempt to enable encryption towards authoritative servers as it becomes standardized by the IETF, or during testing of those standards-track efforts.

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 some cases, 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 a query, it necessarily contains the Reply To address from which the query originated. This Reply To IP address is held only in volatile memory and only for the very short time (microseconds to milliseconds) necessary to service that query and increment the various counters Quad9 keeps. Quad9 counts the number of queries against the various categories outlined in Section 2.2 and then deletes the Reply To address information without storing it in any location.

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 or other stateful protocol or sub-protocol) the sooner of the user or Quad9 closing the stateful 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”, create an account, or otherwise disclose their identity to us, because we have no technical nor 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 the user, and consequently we do not have anywhere to store or any way to retrieve data about users.

2.1 IP addresses

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

Because Quad9 does not collect nor hold user 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 forfeited. Therefore, Quad9’s focus is on ensuring that IP addresses are never correlated with other information under our control which would reveal query name information related to the user. 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 user-facing data collection is principally in the form of integer counters.  We create these counters with several possible cardinality dimensions: 

• Quad9 POP in which the query was received,
• Quad9 IP address to which the query was directed,
• BGP-advertised prefix or de-aggregated CIDR prefix no more specific than /24 for IPv4 and /56 for IPv6, and associated advertising ASN,
• Geographic region (see below for description,)
• DNS QTYPE (A, AAAA, NS, etc.,)
• DNS header flags (TC, RC, RD, AD, CD bits)
• DNS Response code (NOERROR, NXDOMAIN, etc.,)
• Query protocol (TCP, UDP, DoT, DoH(2/3), DNScrypt, DOQ)
• IP version ( IPv4, IPv6) 
• The network-type category assigned to the autonomous system and/or the source IP address, derived using locally-hosted IP open- or closed-source intelligence data,
• Matching status against filter lists

In addition, we may record:

• The count, timestamp of the first and most recent instances of queries for each query label, QTYPE, and Response Record, optionally with any of the above dimensions.
• Histogram-based latency profiles of calculated round-trip speeds of networks generating end user queries to each Quad9 POP, with maximum resolution for IPv4 at /24 prefix length, and IPv6 at /56 prefix length. These latency profiles do not contain any other cardinality expansions.

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 use locally-housed versions of GeoIP and IP classification databases so that we can understand (roughly) how schools, or mobile carriers, or other classes of network endpoints are utilizing our systems. We may also note the first and the most recent time we see a query for each unique query label, along with how many times we have seen that type of request. 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 fully-qualified domain name has been queried, optionally with the associated dimensions.*

None of these counters contain any personally identifiable information, nor do they correlate with or specifically reference any individual query in any way that could be associated with an individual user.*

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 no fewer than 10,000 persons.

For example, Nunavut is a territory of Canada with a population of 42,000, but no city within Nunavut has a population exceeding 9,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 925 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 user.

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 not built any mechanism to collect, retain, analyze, or distribute this information.

2.3.1 Threat Intelligence Event Sharing

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 user or their Internet use.  With the specific threat intelligence analyst that has identified a malicious domain to us, we will reciprocate information triggered by or relating to the end user performing the query to the identified malicious domain, namely:

• The timestamp of each query to the same identified malicious domain
• The count of queries to the same identified malicious domain.
• We may share none, several or all the dimensions outlined in Section 2.2. 

Threat intelligence analysts that have not identified the same malicious domain to us will not receive reciprocal data related to that malicious domain, unless  they have authority and incentive to correct the malicious behavior.

In some cases, it may be that sharing threat intelligence data can reduce or eliminate the threats themselves. As an example: sharing insights on domains ending in a specific CCTLD suffix with the CCTLD operator may create rapid removal of those domains from the threat pool, rather than simply blocking the names at the DNS recursive resolver level. Similarly, sharing volumetric threat data of identified malicious domains that resolve to IP addresses within a hosting provider’s network may encourage that hosting provider to identify or remove the threats, which then significantly improves end-user security by removal of the actual risk.

2.3.2 Traffic summary sharing

Quad9 aggregates or filters DNS data, as described in Section 2.2, for public distribution or for use by third parties who may utilize the aggregated data to discover threats, improve performance, or provide insight into large-scale trending behaviors which may characterize patterns of stability and use of the DNS or Internet. In some cases, the use of the data may be licensed or distributed at no cost, and in other cases licensed for a fee in order to maintain a sustainable source of income to operate the Service.

Quad9 does not relay any PII in these aggregate data exchanges, and we additionally enforce contractual guarantees with any consuming third party organizations that prohibit attempts at using the data (by itself or in conjunction with other external data sources) to reveal PII associated with queries.

Examples of these aggregated data include but are not limited to “newly observed domains” and “domain trend indexes”.

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 the data we provide solely for the purpose of improving user security or improving performance of network and software infrastructure, 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 from time to time, such as number of threats blocked and infrastructure uptime, to the public.

2.3.3 NXDOMAIN Non-Sharing 

In no circumstances does Quad9 share NXDOMAIN QNAME data at the hostname level, nor will we share NXDOMAIN data at the ETLD+1 or root level with any third party.

NXDOMAIN data may contain inadvertent information which was not intended by the client to be visible externally, and so we treat this data with even more care than valid NOERROR responses. Only names that correctly resolve are included in Quad9’s telemetry system as described in section 2.2.  Where Quad9 discovers wildcard zones where all data results in NOERROR, Quad9 will attempt to identify those zones and exclude inadvertently-transmitted data where possible. We may keep counters on how many NXDOMAINs occur within a valid zone cut (all the way down to the root) but we will never share the data to the left of the valid zone component. Example: doesnotexist.quad9.net produces an NXDOMAIN. Since “quad9.net” exists, we will increment a counter for quad9.net to indicate that a NXDOMAIN has occurred, but the “doesnotexist” component of the name is not stored or transmitted in our telemetry system.  

For clarity: queries that return with no resource records except for SOA or NSEC, but also return as NOERROR are considered NXDOMAIN by Quad9. These are known as “Compact Denial of Existence” results, and are treated as NXDOMAIN.

2.3.4 Locally Served Zones - RFC6303 (Non-sharing)

Quad9 answers queries for locally served zones (RFC6303) within our own systems, and we do not transmit or recursively resolve those queries to offsite platforms such as AS112. Additionally, we tag these answers with EDE code 29 (“Synthesized”) to indicate that the NXDOMAIN responses are generated by our systems artificially. 

AS112* exists as a loosely-coordinated volunteer effort to answer for zones that are reserved by IANA. These queries should not be transmitted out of an organization, but AS112 exists to respond to those queries in a distributed fashion in the event that such a query reaches a recursive resolver that is not configured to answer locally. Examples of these types of queries would be PTR records for RFC1918 addresses like 192.168.0.0/16. This type of query may leak some internal data to external, unknown operators and in an abundance of caution we wish to prevent that from happening. Therefore, Quad9 implements a set of response zones that are equivalent to the zones served by AS112, but we serve those locally within each resolver stack on our platform. This means that the queries are quickly and privately returned to the client requesting those records so  the query never leaves our infrastructure, preventing any potential leaks of data sent to zones that are reserved.

3.0 Exception

Like any operator of digital infrastructure, we must maintain the security of our systems in order to ensure the privacy of our users and the stable operation of our services. We have a separate privacy policy for anomalous conditions, such as any in which we believe entities are engaging in cyber attacks against us or which reasonably appear to be using our infrastructure to attack others.

4.0 Correlation of data

We do not correlate or combine data in our possession with data from other sources, except as outlined in this document in Section 2.2 under “network type,” “metropolitan area,” and “BGP prefix and ASN”.

5.0 Result filtering

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

5.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  “filter lists” 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 respective 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.1.

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. Quad9 does not and will not implement block lists that are not able to be discovered by end users, and all domains from all data sets will be searchable and attributed to the source providing the domain. Quad9 marks blocked (NXDOMAIN or SERVFAIL response code result) domains with Extended DNS Error (RFC8914) error enumerators  to indicate artificial responses using errors numbered 15 (Blocked), 16 (Censored), and 17 (Filtered) where appropriate.

5.1.1 Censorship/Mandatory Attribution

Quad9 does not censor the answers it provides for any purpose other than the optional blocking of malicious domains associated with phishing, malware, vulnerability exploit, or fraud, as detailed in section 5.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 of which we become aware.

Quad9 operates within the law. If we determine that legal constraints require us to implement DNS blocking in a way that we believe to be contradictory to the interests of our users, we will take technical measures to remove the risk against ourselves. This may include withdrawal of service from regions where censorship is mandatory. Where our resources make it possible we will attempt to maintain our uncensored service in contested areas while we may use the local legal system to object to censorship efforts, though we cannot guarantee success in our favor nor can we commit to any level of effort in such legal actions. 

Quad9 will not cooperate with any efforts that force mandatory attribution (association of queries with natural persons) for use of the service or which require storage or transmission of query data that is associated with a user’s personally identifiable information. We have no mechanism for this, and will not build tooling to perform this attribution, storage, or transmission. We will not expose ourselves to legal risks in jurisdictions where mandatory attribution is enforced.

5.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 will inform that threat intelligence source that provided the name in order to have them investigate and update their data. If there is no sufficient remediation and Quad9 continues to believe the domain to be a false positive based on investigation, Quad9 will add the domain 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.

6.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 personal 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 this privacy policy in Section 7.

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).

These clauses are for legal compliance, and it is necessary that we put these statements in regardless of if we have personal data or not. Quad9 does not have any personal data about users of the service, so our response to requests for information about personal data will be that our service does not record or store any personal data and are therefore unable to fulfill any requests for such data. Your right to ask about personal data is unrelated to our actually having the data, and Swiss Federal Act on Data Protection (FADP) as well as GDPR provides you with the right to request data to which Quad9 must comply, even if our answer is always “We do not have this data.”.

7.0 Contact

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

Quad9, c/o SWITCH, Werdstrasse 2,  8004 Zürich, Switzerland

-end-

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