Bug#761658: Please do not default to using Google nameservers

[Christoph Anton Mitterer]

On Tue, 2015-04-07 at 23:07 +0200, Marco d'Itri wrote: 
> I do not believe this to be true.
Well, but it is. It's similar to many networks blocking port 25.


> I totally agree with this statement, and indeed systemd-resolved 
> defaults to use DHCP-provided resolvers if available.
Sure, noone disputed that... it's that it has another fallback that
causes concerns.


> Let me point you to the helpful official page which shows that Google 
> does not store personally identifiable information:
> https://developers.google.com/speed/public-dns/privacy .
> This level of privacy is much better than the one provided by the 
> resolvers of many large ISPs.
Such documents are practically worthless:

There is no way to verify that these policies are actually obeyed by
google itself and even, they can unilaterally change it at any time.
There is also no way to enforce these rules since Google (or anyone
else) may sit in a completely independent jurisdiction.

Even if google itself would obey to them, any carriers or organisations
that listen on the way of the data to the google resolver somewhere in
the US are not obliged to follow Google's privacy policies.

Last but not least, it's e.g. well known that say US companies are not
bound to e.g. European data protection laws and that the so called safe
harbour agreement is basically moot.
This has been officially ruled by US courts and if national security
used as a reason than the data is anyway completely out of any lawful
control.


> I have already explained to you that this is not true.
I've showed you my traceroute and it is. 


> > for people in dictatorial regimes where using 8.8.8.8 may not be liked
> > by some governmental forces.
> Can you point to documented cases of people being troubled by oppressive 
> regimes for their choice of DNS resolvers?
It's well known for people using VPNs or Tor in countries like Iran or
Saudi-Arabia, guess it should be pretty easy to find these in news
reports on the web, I don't know of specific cases for DNS though.
But such regimes typically don't publish what they do... so just because
it's not known yet, doesn't mean it's not happening.


> > Could you please elaborate how you feel that the new fallback improves
> > the quality, when like 99,99% of the systems are anyway already
> > configured via DHCP or other ways and there never had been a need for a
> > hidden hardcoded default.
> It makes the other 0.01% (?) systems work.
*If* the nameservers are actually reachable.


> > Could you elaborate on what you plan to do if Google should decide to
> > terminate that service (will there then be an update for all
> > stable/oldstable/etc?), which wouldn't be such a big surprise, given the
> > number of other services they recently shut down?
> Then they would not be worse than with no default configuration.
> 
> > Could you further elaborate on how this affects the systems of people in
> > regions where access to the google name servers is blocked?
> Then they would not be worse than with no default configuration.

> > See above and previous mails from myself and other complainants, it's
> > probably mostly the privacy and surveillance issues, especially since
> These "privacy and surveillance issues" are substantially fictional.
You seem to have missed several years of post-Snowden media coverage.

And even if you choose ignore mass surveillance by governments for your
self (and notice that other people may not want to follow your personal
choice), you can take even simpler examples where such data leakage may
be highly undesired:
Take split DNS setups which are quite common for larger organisations or
basically every intranet.
If you do hidden fall back resolution that internal network topology of
such intranets may be completely revealed to the outside just because
some clients may have the DHCP (or similar) not working and the fallback
servers being used.


Cheers,
Chris.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5313 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20150407/30ed4735/attachment-0002.bin>