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

[Christoph Anton Mitterer]

On Tue, 2015-04-07 at 22:22 +0200, Marco d'Itri wrote: 
> So far the current default looks like a reliable
Actually it's not, many networks block access to external resolvers
since the "proper ones" are given via DHCP.
As it was pointed out here before, protocols like DHCP are the proper
and reliable way to auto-configure the DNS resolvers.
In more than 30 years of DNS, such functionality of a silently hardcoded
nameserver has never been needed, why now?

>  and secure one
Please read the mails from others and my, where countless of arguments
have been presented proving this as wrong.
Starting from privacy issues / data leakage (if you google for the
topic, it apparently seems to be even an open secret, that google
collects the queries people make against their nameservers), mass
surveillance issues (since data goes at least to the US) or even worse
for people in dictatorial regimes where using 8.8.8.8 may not be liked
by some governmental forces.


> , and
> as the package maintainer I do not believe that removing the feature
> of a last resort fail-safe preconfigured DNS resolver would be 
> "no default" would improve the quality of Debian.
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.

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?

Could you further elaborate on how this affects the systems of people in
regions where access to the google name servers is blocked?


> how the 
> current default configuration would be worse than other default 
> configurations.
See above and previous mails from myself and other complainants, it's
probably mostly the privacy and surveillance issues, especially since
the data leakage is completely unexpected, since this new behaviour
breaks with decades of well known behaviour where no hard coded fall
back existed.



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/711af9ad/attachment-0002.bin>