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.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers