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.
smime.p7s
Description: S/MIME cryptographic signature