We’ve Updated Our Privacy Policy

Privacy is, always has been, and always will be paramount at Quad9, so we want to take a few moments to explain the updates made to our privacy policy. It’s been five years since we updated the document, and in 2021 when we did our last edits, the changes were very minor to reflect our Swiss jurisdictional transfer. It is time we reviewed our privacy policy to add additional protections, account for new technology, and provide more insights for our management and telemetry platform which improve our ability to deliver the service and enrich threat intelligence data that protects our user community. These changes we believe continue to guarantee end users the uncompromising privacy of their personal data they have come to expect from Quad9. We hope the document with these changes can continue to be used as a template for others as well.

Privacy is woven into our mission and everything we do, so changes to the privacy guidelines we publish are examined with very close attention to detail. We want to be transparent and forthcoming about the changes, but we also understand that there is a risk of “over-explaining” for things that are merely minor clarifications. We hope the privacy policy itself is sufficient to be self-explanatory, but we also want to give some insights in longer form in this message to allow better understanding of our motivations and the details around the changes.

As always, we collect no personally identifiable information (PII) about our users, as that is a very clear guideline for us. Collection of PII is toxic to Quad9, as not only is it unnecessary to achieve our mission, but having PII creates conditions where we would become a target for inquiry. It is our strong desire to avoid entangling ourselves in the complexities of PII management and the legal constraints it entails. We want to ensure it is understood that none of the minor changes we have made alter this steadfast guarantee of non-collection of personal data.

Changes: Summary

Much of the text of the privacy policy remains unchanged, though we did make some modifications. Why did we make changes in the areas we updated? In general, the reasons were:

• To be more precise in our wording (e.g., removing unnecessary adjectives or hyperbole);
• To fix a number of unclear sentences and statements by adding additional text or examples, to make our intent more clear, and to focus comments specifically on user data to improve on accuracy of interpretations;
• To account for the new protocols we now support and additional privacy extensions that we have made, both of which require slight language changes; and 
• To clearly address the data we measure for operational improvement, research, and sharing as described in more detail, below.

Most of the changes we consider to be “non-impactful” meaning, in our view, they are clarifications of text or additional explanations based on interactions with users or others who have had questions regarding our privacy policy.

Changes: Incremental Collected Data

There are two areas that are more than just minor changes. We have added two significant modifications in our privacy policy which we believe could be considered additive data that we measure, neither of which is PII, but bears more description:

• Network-type Categorization: The addition of network-type categorization to our counter-based collection system. 

• • This means we can report on the number of queries coming from various “types” of user communities (residential, mobile, hosting, etc.) In the process of interpreting several potential and existing grants, and also from questions presented to us by the research community, it became apparent that we were lacking the ability to answer some core questions about our user base from a rough demographic perspective. 

  • We have found an increasing demand to be able to answer broad questions such as: “How many times today did Quad9 prevent malicious activity at schools in Kenya?” or “Are South American or African ISPs more likely to use DOH3 encryption as a percentage of their traffic as compared to European and North American ISPs?” 

  • Without the ability to track categories as a dimension in our counters, it has not been possible for us to answer those questions for ourselves or for others whose research or funding directives mandate understanding those dimensions.  

  • We are adding the ability to create dimensional data using categories from third-party databases so that we may answer these questions.

  • We use a variety of closed and open source tools for this classification, and we self-host the data sets at the edge of the network. In no circumstances do we send the query or IP address of the client outside of the physical host where the query is received. All lookups are done locally, using MMDB lookup tables stored in memory. This is consistent with our strict rules around client IP addresses never leaving the server on which they were received and never being written to persistent storage in any form or kept longer than necessary to respond to the immediate need of the software processing the request.

  • We’re very aware that network-type categorization is extremely challenging to get correct, and all databases have significant shortcomings in accuracy of category, timeliness, and granularity of address resolution. Understanding these limitations allows us to interpret the data with some skepticism, but the data is often good enough to make meaningful generalizations, if not specific answers.

• Latency Histograms: We have added latency histograms on IPv4 and IPv6 client address ranges. As Quad9 has grown, our expertise with traffic management and capacity planning has become more mature. Evaluating merely the quantity of queries received in a location is no longer sufficient to understand end-user experiences, and we needed to have some way to infer the speed at which queries and responses were finding their way across the network. To do this, we are developing the ability to track latency at a generalized level when we see traffic from a client network. Query data is ignored in this collection process; network round-trip time is measured at a lower layer than at the DNS protocol layer. No specific individual IP addresses will be tracked or reported; we will “roll up” answers into IPv4 /24 or IPv6 /56 prefix sizes, which prevents any one IP address from being measured or understood to be sending Quad9 traffic. 

Changes: Clarifying Non-Collected Data

The above two categories are “additive” meaning they expand the dimensions in which we create measured counters, and we want people to be aware of those changes. In other changes that are more conservative of data, we’re also making some non-goals more clear, which have always been true, but we’re simply clarifying our position - these are improvements in our privacy coverage that we’re making as policy instead of just implicit goals:

• Non-tracking of NXDOMAIN Data. We will not track typos or accidental copy/paste events which are frequently seen in DNS data. These are leaks and are not useful or safe to track as they are unique events which entered the DNS unintentionally. We may create counters which track the number of events on the next-rightmost zone cut that is valid, but we do not track the inadvertent data part of the query name in any way.  We have never tracked this data, but it seems to be worthwhile to specifically call out the fact that NXDOMAIN information is never summarized at the level where information leaks would be problematic. Quad9 has never tracked or transmitted this data, but we feel it is important enough to call out as a specific non-tracked element.
• No invisible blocking. Quad9 provides an optional security-filtered service on 9.9.9.9 and other security-enabled endpoints  (we have also always offered a non-blocking service on 9.9.9.10 and alternates.) When we block a name that has been provided by a threat intelligence provider, we now flag that blocked event using RFC8914 Extended DNS Error (EDE) codes in addition to our legacy blocking flagging model (setting “recursion available” to zero). Additionally, we allow any domain to be searched on our web search page, and if we are blocking the domain we will indicate which threat intelligence provider gave us the blocking data. We will never block domains in an opaque way that hides the fact that these are non-natural NXDOMAIN or SERVFAIL results - there are no “secret lists” that we operate or that we are being forced to implement. If we block a name, it is possible to find out where that blocking data originated. This prohibition of undocumented blocks has always been the case at Quad9, but the privacy policy now makes this stance more publicly and clearly documented.
• No mandatory attribution. There are legal or regulatory movements in various jurisdictions to demand that transactions on the Internet are logged and associated with individuals, and in some cases there are implicit outcomes in those regulatory efforts which makes it possible to demand that this data be available on request by government authorities. While the relative merits of this general policy model may be debated at the content level, we believe that the DNS, along with the underlying TCP/IP network protocol that defines the Internet, should both remain available for use without relinquishing personal data. We will not willingly participate in any demands for identity to be required for recursive DNS resolution in our public services and will remove our services from availability in a jurisdiction if legal conditions require us to collect or transmit such data. Successive UN Human Rights Council resolutions have recognized Internet access as essential to the exercise of fundamental rights including freedom of expression, freedom of association, the right to education, and participation in cultural and political life and have called on states to adopt a human-rights-based approach to expanding access. We believe unfettered and unmonitored access to the global DNS is a fundamental component of Internet access as those basic freedoms are described by the UN. This again is a long-standing policy which we are putting more clearly into our privacy documentation.
• No leakage of AS112 queries. For some DNS zones that IANA categorizes as “private” there is a volunteer-led effort to answer for those names in a scalable way, under the general concept of “AS112” (read here for more details on this). We think AS112 is a great idea in general, but we also think given our stance on privacy we should be handling those answers ourselves and not relying on third parties on unknown networks to provide NXDOMAIN responses for those questions. We were previously partially blocking most queries from reaching AS112 destinations, but now we’ve added additional zones we answer locally so this should now be 100% coverage of those names. There are a surprising number of queries that go out to those reserved zones - as an example, 1.1.168.192.in-addr.arpa is within that reserved namespace. Some recent presentations made us re-evaluate all of the possible zones in this set and how we answer them. We now make it possible for users to tell from whom and why the answers were being given. We’re now using extended DNS errors (EDE) to tag these responses as “synthesized”, and we’re also adding (upon request by NSID bits) the nameserver data to those queries to assist in debugging. This is a fairly esoteric privacy extension, but for some users this may solve both a very slight privacy leak as well as be a latency improvement if they are sending significant traffic to RFC6303-listed address space.

Summary and Future

We believe these changes make our privacy policy stronger, more clear, allow us to better manage our own network, and update our guarantees to our users. 

The aggregate data we collect has been used internally for performance analysis and debugging and also has been shared with trusted academic and industry researchers to help them identify threats or understand patterns in DNS behaviors. We continue to work with the research community where our resources allow, and we will also continue to expand our work with threat intelligence and performance measurement partners to identify ways we can help improve the protections we (and others) provide and also increase the speed of user data across the Internet. In some cases this data is made available at no cost, and we will continue to try to create commercial and sponsorship opportunities for Quad9 to remain viable using this aggregate data as a method for bringing in grants or income where it is mission-aligned and falls within our privacy guidelines.

As the breadth of our data has increased, so has the value it contains. Understanding the generalized activities of query and response behaviors of the DNS is valuable primarily to threat intelligence firms as they focus on new ways to determine where threats originate and then how to stop them. Quad9 needs to have a sustainable income stream for continued expansion, operations, as well as the costs of legal defense and administrative overhead which arise from having a focus on privacy and security. We have in the past given away (or traded for “in-kind” value) variations of aggregated data from our telemetry network, but we are developing a more formal commercial mechanism for receiving funds from organizations that can afford to purchase signals that they use to improve their own products. We wish to have Quad9 participate in revenue opportunities if our data is being used to create a valuable asset downstream. Again, there is no personal data in this exchange - we don’t collect it, so it is not possible to transmit. 

These improvements by commercial organizations protect their end users and in many cases are looped back into Quad9 to protect our user community as well - this is a virtuous feedback cycle that we hope will continue to improve security for a wider group of beneficiaries and not just Quad9. We’ll have more on this shortly as we try to diversify our support to ensure long-term sustainability as we continue to grow.

We remain fully committed to the concept that individual user data is never collected or compromised, and we hope that these clarifications and modifications to our privacy policy reflect that commitment. We welcome comments and questions - please send them to support@quad9.net, and we will try to respond to messages from our user community.