By not collecting any PII. No. That’s an obviously false statement, and doesn’t usefully contribute to the conversation. Quad9 collects: - Aggregate count of IPv4 queries per site - Aggregate count of IPv6 queries per site - Aggregate count of UDP queries per site - Aggregate count of TCP queries per site - Aggregate count of TLS queries per site - Aggregate count of HTTPS queries per site - Aggregate count of DNScrypt queries per site - Aggregate count of queries matching each blocked domain per site, for queries which are directed to the malware-filtering addresses. In the future, Quad9 may also count aggregate number of queries matching blocked domains by origin AS, but there’s no active project to implement that. If you see a privacy problem with any of that, please tell them. Or tell me, and I’ll pass it along. The entire purpose is to improve privacy and security. If they’re not actually doing that, they’re failing, and there’s no point in doing it if it’s failing. While you’re right, that has no bearing, since the labels aren’t being collected. Or do you mean RFC 7816? Yes. I believe it may not be entirely rolled out in production yet, but that may have gotten finished while I wasn’t looking. Can you ask the question more explicitly? I don’t understand it as stated. Exactly. And in Quad9’s case the reason is because privacy regulators were looking for an exemplar to use in their argument that collection of PII wasn’t a business requirement for operating a DNS resolver. To the best of my knowledge, I’ve spent the past thirty years doing the opposite. If you have some reason to believe otherwise, please bring it to my attention. -Bill

The word “collect” is generally understood to mean “record” or “retain” and I’ve used it in that sense. By intention and design, neither of those are true for Quad9, with respect to any PII. No PII is recorded or retained, except in the sense that the source IP address of any query is used to address the reply. No, that’s false. Please read RFCs 7816 and 7871. Quad9 implements the former and not the latter, in order to minimize the leakage of data from end-user to authoritative server. Moreover, that’s only an issue with zones for which PCH is not authoritative. For all those for which PCH is authoritative, no queries pass “through” to anywhere else. Again, if, after acquainting yourself with Quad9’s practices and the relevant RFCs, you see any way in which Quad9 could provide better privacy or security protections to users, they would VERY MUCH LIKE YOUR CONSTRUCTIVE INPUT, as that’s the entire point. It’s an open and transparent community project, to serve the community. Which is why Quad9 was the first global anycast resolver to implement DNSSEC validation, and why PCH is the only DNSSEC operator besides ICANN to implement FIPS 140-2 Level 4 security. Only if “the data” is collected in the first place, and I regard doing so as a failure. If data is collected, it will inevitably be breached or disclosed. The only defense against this is to not collect data in the first place. Which, again, is the entire point of Quad9. Exactly. The reasonable thing to do is to operate your own RFC 7816-compliant caching resolver at your border, and use a recursive resolver with policies that match your self-interest. And that’s what ~95% of Quad9’s users do, to the best of their understanding. Which is admittedly/purposely/by-design a limited understanding, since there’s no institutionalized concept of a “user.” However, since it’s a community, there’s a lot of discussion and mutual support and exchange of anecdotal information. And during the pilot (November 2016-November 2017) there was active interaction with the pilot users. Completely agreed. Unfortunately, nearly all large ISPs and many small ones are doing this, though usually not in as obvious a fashion as you observed. Most outsource operation of “their” resolvers to companies which monetize on the back end, without changing the IP address. -Bill

TLDR: - https://quad9.net/policy/ and https://quad9.net/privacy/ are the multiple pages of legalese - it is a long text, not actually mentioning any actual technology - nobody using 9.9.9.9 will read it as they are using an IP, not a website with text - it can change whenever, there are no versions, there is no history of what changed (archive.org possibly) - for a variety of reasons IP (and thus PII) might be gathered anyway - IP prefixes are summarized, but unknown till which size (IPv6 /48?) - Undefined what happens with packets towards 9.9.9.9 (is somebody doing PDNS, or otherwise grabbing bits?) - Nothing mentioned about RFC7871 (EDNS Client Subnet) which is required for helping CDNs/Geo-DNS... more inline ;) Oh and for the record: Woody, you are not the "problem" here, the companies around Quad9 though, they have a commercial interest in the data... somebody has to pay for it, and that can mostly only be solved with the personal data collection.... nothing is for free in the end and bills (and woody's :) have to be paid. On 2018-11-01 06:24, Bill Woodcock wrote: [snip] That is indeed a great start, what one does not have, one cannot abuse. Strange as https://quad9.net/privacy/ reads: "We share anonymized data on specific domains (such as domain, timestamp, geolocation, number of hits, first seen, last seen) with our threat intelligence partners." That says "Domains" and possibly labels. It also says "geolocation" which is derived from an IP, which can be wildly wrong but also extremely specific... It is not specified at all what is actually really collected. It would be great to have a list, or a log example or heck the tool (as it is likely open source...) of what is actually logged/collected/"shared with partners". But more importantly, for us 'geeky people' who run our own domains, that domain identifies an individual and thus a domain in effect points to PII..... while 'gmail' is general, 'massar.ch' is not so general any more... Next to that labels can include IP addresses (e.g. 1.2.3.4.in-addr.arpa, but also the forward 4-3-2-1.dsl.isp.example) Noting that these are looked up by every SMTP server on the planet. Are you saying you are dropping these labels? As otherwise, you are collecting PII. https://quad9.net/policy/ reads: "This policy may be amended by Quad9, and the new version of the policy shall become effective upon its posting " so, as it is not versioned, and previous versions are not available, that 'policy' can be changed any time. Today it might look okay, tomorrow, it will not, and then 9.9.9.9 is hardcoded like 8.8.8.8 and nobody gave consent on the change in policy. Lets look a bit deeper: "When you use Quad9 DNS Services, the information we gather aides us to personalize, improve and operate our infrastructure. " Personalize? So, as in, P(ersonaliz)eII , how does one "personalize" when you claim to not collect Personal Information? "Our normal course of data management does not have any IP address information or other PII logged to disk or transmitted out of the location in which the query was received." What is the "not-normal course"? When is that applied? What happens then? Did you note the 20 pages of legalese I mentioned, indeed, there is about that amount on those pages. Would be cool to have a bullet list of what is collected... "We may aggregate certain counters to larger network block levels for statistical collection purposes" So, you keep addresses, but at "block" level. For IPv6, is that on /64, /56 or /48? And for IPv4 /31? ... would be great to specify otherwise that is a meaningless statement. "observed behaviors which we deem malicious or anomalous" Is "trying to resolve a malware URL" considered "malicious"? would be great to specify this. (I guess what I know what is written, but hey, it is a policy, thus legalese and thus, needs to be specific). "We do keep some generalized location information (at the city/metropolitan area level) so that we can conduct debugging and analyze abuse phenomena." Are you saying that certain "cities" have more abuse than others!? :) Look, just state that for debugging, IP addresses will be seen, nobody minds they are in the clear. But just do not log it and definitely do not automatically share with "3rd parties"... I'll skip commenting on the cookie section as that section just violates any form of 'privacy'... "Quad9 does not store PII IP address data on permanent storage methods (disk) or transmit that data out of the datacenter in which the query was received." Funny, it actually says exactly that it shares those things with 'partners'... I'll also skip over that "partner" means $world when one talks about companies the size of IBM, everybody is a 'partner' (google uses that same tactic in their 'privacy' policies) [snip] How is privacy and security improved by sending packets to a third party one does not have a financial incentive with (if you are not the customer, you are the product)... Somebody pays for the infra, thus what are they getting back? Simple embedding of IPs in labels. See above in-addr.arpa and dsl.isp.example examples. But speaking of RFCs.... RFC7871 (ENDS Client Subnet) is not supported to optimize all that GeoDNS traffic? No mention in the 'privacy' or 'policy'. Would be good to just list the technologies used. ISPs do not have to collect it either, and people already have a relationship with them and locally, with low latency and full support desks to help people when there are problems. Thus the example one is looking for is the ISPs. Though of course, in the US this might be quite different from other countries where ISPs work against their customers instead of for them... You indeed have, but the companies involved in quad9 have not... and while previous work has been awesome, this is a bit the opposite and centralizes things. Greets Jeroen

On 2018-11-01 21:53, Rainer Duffner wrote: At least everybody running unbound is (as it is the default) and unbound is very often deployed in high-speed recursor situations. Do note that unbound has a not-default-on strict mode. That means in non-strict mode (default) it will retry when failures happen. (As such, a MITM/bad-authoritive could introduce a failure to learn more) The config option reads and explains reasonably well: ------ qname-minimisation-strict: <yes or no> QNAME minimisation in strict mode. Do not fall-back to sending full QNAME to potentially broken nameservers. A lot of domains will not be resolvable when this option in enabled. Only use if you know what you are doing. This option only has effect when qname-minimisation is enabled. Default is off. ---- Exact details are in the archives of the unbound mailing list... Greets, Jeroen