Re: Google DNS on Salt Mobile
Bill Woodcock <[email protected]> Wed, 31 Oct 2018 22:24:17 -0700
| Newsgroups | gmane.org.operators.swinog |
|---|---|
| Message-ID | <[email protected]> |
> On Oct 29, 2018, at 11:38 PM, Jeroen Massar <[email protected]> wrote: > > On 2018-10-30 00:25, Bill Woodcock wrote: >>> On Oct 29, 2018, at 1:16 AM, Gregor Riepl <[email protected]> wrote: >>> It seems like Salt is no longer supplying their own DNS servers when >>> establishing an LTE connection. Instead, the network responds with Google DNS >>> servers (8.8.8.8 8.8.4.4). >>> I'd rather not send all my DNS requests to Google. >>> Perhaps it's time to switch to private resolvers everywhere, if not even ISPs >>> are providing that service any more… >> For what it’s worth, there’s a Quad9 server cluster in Zurich, and >> unlike Google, Quad9 is GDPR-compliant. As someone will certainly >> point out, it’s also subject to US law, but is a public-benefit >> not-for-profit corporation, and US law doesn’t compel an organization >> to turn over data which isn’t collected in the first place. And Quad9 >> is GDPR-compliant because it doesn’t collect source IP addresses in >> the first place. > > How can something be "GDPR compliant" when no consent is given at all? By not collecting any PII. > Have you layered HTTP on top of DNS to provide a 20-pager of legalise that nobody can be bothered to read as it will change at a moment's notice? No. > Stating "it doesn’t collect source IP addresses" means "but we collect everything else”. 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. > IP addresses, especially sources, sometimes also appear in the label, simply because some weird CDNs/ISPs will encode the source IP for 'geo-dns' or 'loadbalancing' reasons in the label. While you’re right, that has no bearing, since the labels aren’t being collected. > Are you stripping those? 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. > And then there are RBLs, and reverse-IPs in general. Do you filter those? Can you ask the question more explicitly? I don’t understand it as stated. > There are many reasons why so many of the public DNS resolvers popped up: one of them is the amount of data that can be extracted from it. 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. > Please stop centralizing this Internet thing…. 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 _______________________________________________ swinog mailing list [email protected] http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
signature.asc
(application/pgp-signature, 833 B)
-----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEm6XJ0FdpKWJHso4lb6RwSyiLf4cFAlvajgEACgkQb6RwSyiL f4ci6g/+Ibx1f/zBcc/L7rb+j0fS6NAP5D0nHUQd1cAsbiauwZT9wZs90cizhm94 1chsEI7749MrqEAIk8nl7ZKbjcgEds3oxNvXawMX8M+W8tBVdZFNZYDSa1FkT51m gXq8dru5lgB3LoXEHzN9vwkSLT38diIniDXu4pKtXJCcubo+spMZlkFryNlqoW1t lkGajBbLE6zkEbXJytXe53wdMbr0kWdQzyogRgYmGrU5HLruJKLiQifavdGCECKv 5svII7PcAZU/YXV/csLC+5jciyqrerWLqoas7+BhXGtdzd4U9llVc97zkxfZUS0D fjs1Ls6Ox1mCHMHUnAt88ekWavVxCRKzvdZpIn+IvMpAKP/y9si2YZA0oxS0Glrw rGYsf8PlH1eP6CtbG9EaFuFjwDKihUShDRinKiTKJv9JL8/ZN3+raKxw+Kci8qWU h3eQbmPgRcMj9tRUsens3MGT0DD1eQQrBSGulF2hBprcpHqBt2pLhZq4zt51jeHQ WmeKIn+BoolRuj9d4aEUEjeoWwUDhLUtEZ3H23U7he/c3APzj187ujMkevoXr0LN zm3stJ9D0L1PWy7kKTKAC8texJ/qQaxQH2tfL+HBgUcYcClbcpaudyL7c6KwUbWL UZURCqXnovTCXD680pOTtcrr68oiQIeWB/ZcJDhC6MPIr7Yc6a0= =oEnI -----END PGP SIGNATURE-----