There isn’t really any evidence for what you claim, either.
Yeah, why can’t it be? I can privately show you those emails, but you didn’t even ask. You just assumed I’m lying. But let’s “hopefully wait for NextDNS to reply” and give them all the benefit of doubt there is until they do and second guess everything else. Astonishing double standards.
I fully deserve your scorn for engaging in good faith, because I’m also an idiot (like you imply as I don’t know what lawyers are and what NDA is).
Neither does Quad 9 DNS. Why single them out?
Quad9 safeguards our users’ privacy by not collecting our users’ personal data; we serve the public benefit directly, rather than profiting from their personal data.
That data still remains the intellectual property of NextDNS though. So I honestly don’t know where you’re going with this. Yes they use other services and those services have the data to offer NextDNS service.
I didn’t assume you’re lying, and in fact never said that. I said there is no real way for me to know if it is true as I can’t verify it. I didn’t think to ask you for the emails though. If you were under NDA that would be a breach.
Why even bother mentioning it if you weren’t going to provide proof? That’s the issue, arguments from from authority are generally a substitute to providing evidence people can see with their own eyes.
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.
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.
This data doesn’t seem specific and is about tracking quality of service in my opinion
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
The data doesn’t even appear to be anonymized, it’s just some statistics of how much of a thing they are doing.
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.
This is an exceptionally clear Privacy Policy though. I think in the past when Quad9 was added it was not that clear.
Personally I’d vote to make this a “No” in the logging section. They simply do not log queries from customers or information that can identify customers.
Inclined to agree we should be more verbose about our specific criteria, the DNS page seems to rely heavily on our general site-wide criteria instead of having DNS-specific items. We can come up with a set of DNS criteria more like our email/VPN sections, our current criteria doesn’t mention logging despite that being a consideration, so it’s not clear
I think we are talking past each other. If a VPN provider stored logs in some über secure location and yet streamed them through GCP/AWS/Cloudflare (with them having plaintext access), would you still call their “log storage feature” a plus? I mean, privacyguides has been more critical for a lot less on other projects (like Windscribe, for example).
I said nothing about disclosing who or what. Just the comms that happened outside the NDA. But anyway, it doesn’t matter. It isn’t important insofar that DNS service providers, in the name of threat Intel, may be in breach of privacy in ways PrivacyGuides might want to highlight before recommending such services without reservation.
You insist my arguments are “from authority” even though you agree with the arguments I made (that cloud providers may be disclosing data to law enforcement, that DNS logging is as bad as VPNs snooping on SNI and IPs). I really don’t understand why you’d personally attack me while agreeing with me?
Neither does Cloudflare DNS except for 0.05% of requests in-memory for debugging and DoS protection.
Cloudflare will only retain or use what is being asked, not information that will identify who is asking it. Except for randomly sampled network packets captured from at most 0.05% of all traffic sent to Cloudflare’s network infrastructure, Cloudflare will not retain the source IP from DNS queries to the Public Resolver in non-volatile storage. These randomly sampled packets are solely used for network troubleshooting and DoS mitigation purposes.
Sampling logs is standard for any public resolver (rethinkdns doesn’t even do that) that limits queries in some form (for example, ControlDNS routinely blocks a range of IPs that they judge to be abusive. They couldn’t do so if they had “no logs”).
Even if you turn off NextDNS logging, they need some mechanism to determine if a free account has crossed their 300k limit. Again, some form of in-memory or disk-based metering is needed, that can be traced back to an account (in NextDNS case, it is email-id).
You can select the country you want store the logs or disable it entirely. I think at the point you’re trusting NextDNS to do logging, it really doesn’t matter what platform they use.
On that topic we’ve been in contact with Windscribe and are going to add that to the site, as we recognize it is a good provider. Just waiting on them to release iOS source code (as it’s currently not available).
I was referring the comments about the number of requests per year processed by RethinDNS and the NDA thing. These really don’t have any relevance to the discussion.
Technically they keep it for 25 hours but don’t log it which is more than quad9 keep it.
A Public Resolver user’s IP address (referred to as the client or source IP address) will not be stored in non-volatile storage. Cloudflare will anonymize source IP addresses via IP truncation methods (last octet for IPv4 and last 80 bits for IPv6). Cloudflare will delete the truncated IP address within 25 hours.
That data however doesn’t necessarily indicate is the revolver’s IP address. That is what people are going to really care about when they use these services.
That could be a simple integer value assigned with an account. Technically still no logging if they’re not keeping the contents of the query ie which domain.
I guess we need to ask ourselves do we want to consider integer counting “a log”. I think if we do that we won’t end up with any DNS providers on there.
I also think we’re quite clear that if anonyimity is something you’re trying to attain then encrypted DNS isn’t the solution to that issue as data can leak from your client in a number of other ways.
Except that’s not what the PrivacyGuides website points out. It specifically calls out storage location without mentioning that logs are streamed worldwide via BigCloud:
- You can choose retention time and log storage location for any logs you choose to keep, or disable logs altogether.
+ You can choose retention time and log storage location for any logs you choose to keep, or disable logs altogether.
+ The only way to access the logs is either via nextdns.io dashboard which streams them over Cloudflare or via their API which uses (GCP/AWS?), and it is possible these providers have access to your logs in plaintext.
You might want to go back a few replies and read what you wrote: I have unfortunately noticed a theme with quite a few of your replies which have an element of argument from authority Please stop gaslighting me on top of calling me dishonest / insinuating that I can’t prove my claims.
The relevance is for PrivacyGuides to do due diligence on dns0.eu before recommending it as “no logs”. Jonah gets that and created a github issue for it. So, it did have relevance.
Depends on the people and the threat model. If they trust PrivacyGuides and see “no logs” (a very strong guarantee), then they assume there’s absolutely no logs. I mean, words mean things. There’s a reason Mullvad goes to the extent they do with diskless servers, verified boot, no remote shell (which they’re working towards etc). To lump, Mullvad’s DNS as “no logs” in the same breath as other DNSes is really being disingenuous, imo.
More assumptions, and just a few comments ago, you accuse me of speculation? My only point was, why not ask them instead? If they won’t reply, why make your own assumptions? Is recommending a service more important than recommending a good one? What’s PrivacyGuides charter? Also, I find it weird someone would defend something they’re not affliated with to the extent you are, because I genuinely feel you’re not addressing the specific points I am making at all, and going off on some tangent about how absurd it is to demand “no logs” from DNS providers.
The reason we don’t mention “Big Cloud” is because it doesn’t really impact the threat model. If you don’t trust the Privacy Policy of NextDNS and their suppliers then you need to employ anonymization (Tor, VPN etc).
None of the encrypted DNS providers advertise themselves as being anonymous, simply that they do not log. This has been discussed elsewhere, but Privacy Guides doesn’t need to constantly keep an eye on every provider’s sub processors. The reason for this is there can be a variety of sub processors and it can be impossible for us to truly know depending on what they are used for. It can also change and we would have to constantly check every provider by essentially re-valuating every recommendation. Even then we only see the outside picture.
That being said we are attempting to encourage NextDNS to provide a little more detail in that regard. The data is still bound by NextDNS’s privacy policy, we’re up front that account usage has logging by default and you might need to disable it. They are very clear in their privacy policy that they don’t sell that data.
Mentioning if it was irrelevant to the conversation taking place regardless of if there is public evidence of it.
There were also some posts in the other thread about Cloudflare and the MiTM thing (when we don’t even use them as a CDN and only as nameservers). Then the goal posts moved to CF being able to change our DNS records, when that is not in our threat model. A lot of the posts you make have a authoritative tone ie: we should be doing this or that. Then there was the HPKP suggestion when it isn’t even a relevant security feature anymore.
Keep in mind as you’re flaired as RethinkDNS people might be willing to give your opinions more weighting in a debate, than some random forum user. The reason I did flair your account was because you do offer similar features to what NextDNS does with the RethinkDNS Android app and I think it’s important for people to know that. Also when people ask about RethinkDNS, you’re able to respond in some official capacity.
Even with Mullvad it’s still a “promise”. It’s also worth noting that Mullvad’s main business is a VPN and their intention is to provide anonymity. They purposefully collect no data so they cannot be asked for it.
Most of these DNS providers don’t purport to offer anonymity, which I think is the key difference. The DNS page doesn’t suggest that using an encrypted DNS promises any kind of anonymity, only confidentiality with regard to queries. This is further made obvious on the “Learn more about DNS” page which provides demonstrations of where internet usage can leak in other ways.
If you see the further comment there, it will likely result in further clarification of what logging is. I think it’s fair to say in most people’s minds that is going to be association of queries with resolver IP address (PII - Personally Identifiable Information) and not some rough global metrics that don’t identify anyone.
The dns0 privacy policy is quite clear at least in my opinion:
We do not log any Personally Identifiable Information (PII).
Our recursive DNS service, this website and other services we provide are fully compliant with the GDPR, and we welcome audits from reputable European entities.
While they don’t elaborate on what they do log, they are very careful to state they don’t log PII which has to be people’s IP addresses. A DNS query is quite a simple transaction. A query is made and an IP address is returned. There is no account based feature with dns0.eu so that simplified things somewhat.
ODoH and DNSCrypt v3 build it into the protocol. So yes, providers that bill for anonymity exist.
It isn’t about “threats” but about privacy, strictly speaking. Though, I get your point.
For any org that claims “GDPR compliance” must be listing down these subprocessors, no? I get that PrivacyGuides isn’t a GDPR enforcer on behalf of the EU, but then again, PrivacyGuides is also recommending something that in its own eyes has gaps in its own privacy policy and potential misleading claims about “GDPR”?
The words you use: “encourage” “little more detail” stand in stark contrast to how I’ve seen PrivacyGuides operate when making other recommendations. I digress.
Please stop attacking me. It can’t be this hard to be nice for once?
I wasn’t aware Google was backing down from HPKP as their OS (Android) and its cert-pinning mechanism remains a credible deterrence against rouge CAs (even if cert-pinning has the same problems or worse problems than HPKP).
Not my style. Will you please quote my exact words so I may know where I demanded anything from anyone here?
No, we don’t. We’re Android-only. The DNS server “exists” for anti-censorship purposes (quite a few anti-censorship projects use RDNS as one of the default DNS resolvers) and has blocklists but the similarities with NextDNS stop there.
Is that why you keep insulting me so people wouldn’t? That explains a lot. /s
Fair.
Client IP needn’t be the only PII in a DNS request or even DNS query. But: I get your point.
Depends on the query.
My point was: for a system with 100+ servers world-wide, I don’t think abuse prevention is merely a single integer somewhere. Now, if I point out I’ve built services running on more than 100K servers, you’ll pile up on me, so I’ll leave folks to their bubble where a single integer magically solves problems relating to abuse, auditing, metering, and what not.
Neither of which are implemented in any OS resolver or browser to my knowledge. RFC9230 was marked as experimental in June 2022. DNSCrypt v3 is still a draft in early stages.
Apparently not , the provider just needs to retain a list of them. Though on this I am no GDPR expert. It also seems it depends on the complexity of the product. @ph00lt0 would be able to give a better answer I am sure.
I sent them an email and made the suggestion. There isn’t much more I can do.
Calm down i haven’t insulted you. I just pointed a few things out from how it looks.
No, you would be in a position though to suggest what specific types of data would not be a simple counter however. That way you’re presenting us with a fact to convince us of your position.
Is the criteria to list some protocol on PrivacyGuides that it has to be a standard? News to me. Should clarify that somewhere I suppose.
The “Tor” protocol isn’t implemented by any mainstream “OS”. Recommended or not?
The official clients for ODoH and DNSCrypt are cross-platform (including installable on open-firmware Routers). Not enough?
From what I know, Apple uses ODoH for its iCloud Relay. That’s potentially millions of users. While Cloudflare runs ODoH across its network (potentially 10s of 1000s of servers).
Almost as if no one moderates what goes on and what doesn’t on privacyguides.org (:
Apologize or don’t but at least don’t question my intelligence.
Also: Waiting for you to quote me on where as some dictator I demanded things from moderators here.
Respectfully, I didn’t build this magical system that can prevent abuse, audit, account for users across 100+ servers with a single integer. Whoever built it, it behooves us to ask them (and not assume) if indeed our collective hallucination is seeped in reality.
It is not, but it does more than encrypt your DNS queries.
They are, but you have to install them, still. Without other the data being protected there will still be leaks obviously as it only protects your DNS resolution. Which means if you’re intending on a anonymous solution, by itself it isn’t very anonymous.
iCloud Relay does more than just throw ODoH at the problem, it actually has connection proxying too.
