> On Nov 1, 2018, at 12:45 AM, Gregor Riepl <[email protected]> wrote: > >> Quad9 collects: >> >> - Aggregate count of IPv4 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. > > As any other centralised service, a DNS resolver will implicitly collect…
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.
> …and pass on any traffic that goes through it.
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.
> Integrity is a bigger issue and there are many examples where it is actively
> being violated - this is at least partially addressed by DNSSEC.
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.
> The question is what happens with the data.
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.
>> While you’re right, that has no bearing, since the labels aren’t being
>> collected.
>
> In the end, this is a question of who you trust and who you don’t.
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.
> My initial complaint was more directed at the fact that an ISP is
> delivering data about a customer's habits to the one of the biggest service
> providers on the planet on a silver platter, and without their customer's
> consent to boot.
> That's not ok.
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
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ swinog mailing list [email protected] http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
