Bug#761658: Please do not default to using Google nameservers
Am 08.04.2015 um 09:55 schrieb martin f krafft: also sprach Marco d'Itri m...@linux.it [2015-04-07 22:57 +0200]: We don't enable AVAHI nor do we install cups-browsed to make things work out of the box. Don't we? Then we probably should do it on desktop systems, since autoconfiguration greatly improves the user experience. Yes, it's great that we have a desktop-task or whatever it is which allows an admin to opt for such autoconfiguration. Just like resolved needs explicit opt in by the admin (the service is disabled by default). Also, it writes the resolv.conf to /run/systemd/resolve/resolv.conf. So the admin needs to explicitly replace /etc/resolv.conf with a symlink to enable this feature. Also, 99,9% (or more) do not even need the fallback, because they've setup their DNS config statically or via DNS. Also, the fallback is clearly documented in /etc/systemd/resolved.conf, so the fallback DNS entries are by no means hidden, as was claimed somewhere else. Honestly, this is a tempest in a tea pot. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#761658: Please do not default to using Google nameservers
also sprach Michael Biebl bi...@debian.org [2015-04-08 10:45 +0200]: Just like resolved needs explicit opt in by the admin (the service is disabled by default). Also, it writes the resolv.conf to /run/systemd/resolve/resolv.conf. So the admin needs to explicitly replace /etc/resolv.conf with a symlink to enable this feature. In this light, I agree that there is no urgency.¹ How likely to you regard the possibility that resolved will become non-optional in the near future? ¹) I'd still like a firm position by the project on such points, and I think we should avoid defaulting to 3rd-party-services over convenience. -- .''`. martin f. krafft madduck@d.o @martinkrafft : :' : proud Debian developer `. `'` http://people.debian.org/~madduck `- Debian - when you have better things to do than fixing systems even if you persuade me, you won't persuade me. -- aristophanes digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
Bug#761658: Please do not default to using Google nameservers
Am 08.04.2015 um 11:33 schrieb martin f krafft: also sprach Michael Biebl bi...@debian.org [2015-04-08 10:45 +0200]: Just like resolved needs explicit opt in by the admin (the service is disabled by default). Also, it writes the resolv.conf to /run/systemd/resolve/resolv.conf. So the admin needs to explicitly replace /etc/resolv.conf with a symlink to enable this feature. In this light, I agree that there is no urgency.¹ How likely to you regard the possibility that resolved will become non-optional in the near future? I have no idea, sorry. ¹) I'd still like a firm position by the project on such points, and I think we should avoid defaulting to 3rd-party-services over convenience. Then you need to raise that on debian-devel and not single out systemd. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#761658: Please do not default to using Google nameservers
also sprach Marco d'Itri m...@linux.it [2015-04-07 22:57 +0200]: We don't enable AVAHI nor do we install cups-browsed to make things work out of the box. Don't we? Then we probably should do it on desktop systems, since autoconfiguration greatly improves the user experience. Yes, it's great that we have a desktop-task or whatever it is which allows an admin to opt for such autoconfiguration. Also, your arguments about Debian having no defaults look a bit empty when looking at your original bug report in which you suggest OpenNIC as an acceptable default. I've managed to better understand the issue since. So no, no concrete threat model. But I hope I was able to argue that Cool, everything is still OK then. No it's not, as can be clearly seen by the numerous other correspondents asking you to reconsider your position. also sprach Michael Biebl bi...@debian.org [2015-04-07 23:13 +0200]: The printer task does actually install both avahi and cups-browsed, for the reasons you mentioned, i.e. make it work out of the box. See above. I'd be fine with a autoconfigure-task which sets the defaults if such a task made it abundandtly clear that it ranks convenience higher than privacy. But just installing a printer spooler does not enable broadcast-based autoconf. -- .''`. martin f. krafft madduck@d.o @martinkrafft : :' : proud Debian developer `. `'` http://people.debian.org/~madduck `- Debian - when you have better things to do than fixing systems anyone who is capable of getting themselves made president should on no account be allowed to do the job -- douglas adams digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
Bug#761658: Please do not default to using Google nameservers
also sprach Michael Biebl bi...@debian.org [2015-04-08 11:44 +0200]: In this light, I agree that there is no urgency.¹ How likely to you regard the possibility that resolved will become non-optional in the near future? I have no idea, sorry. Hm, I was looking more for a statement like nothing is planned, but if we go there, then obviously this issue needs to be revisited. ¹) I'd still like a firm position by the project on such points, and I think we should avoid defaulting to 3rd-party-services over convenience. Then you need to raise that on debian-devel and not single out systemd. Yes. Fun! -- .''`. martin f. krafft madduck@d.o @martinkrafft : :' : proud Debian developer `. `'` http://people.debian.org/~madduck `- Debian - when you have better things to do than fixing systems a gourmet concerned about calories is like a punter eyeing the clock. digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
Bug#761658: Please do not default to using Google nameservers
On Wed, 2015-04-08 at 10:45 +0200, Michael Biebl wrote: Just like resolved needs explicit opt in by the admin (the service is disabled by default). I don't think that this actually changes anything. Everything is in a way explicitly opt in, when you install Debian. The point is can some behaviour be expected or not and is some behaviour and unnecessary privacy leak or not. Moreover, Debian is an Opensource project and not a corporate OS, so we should probably not choose a single vendor and advertise the use of his services. Also, it writes the resolv.conf to /run/systemd/resolve/resolv.conf. So the admin needs to explicitly replace /etc/resolv.conf with a symlink to enable this feature. Also, 99,9% (or more) do not even need the fallback, because they've setup their DNS config statically or via DNS. Which makes it just more a question why this behaviour is insisted upon when it has clearly documented disadvantages. Also, the fallback is clearly documented in /etc/systemd/resolved.conf, so the fallback DNS entries are by no means hidden, as was claimed somewhere else. I think that's relative. Nothing is hidden in the sense that it's open source, but one cannot expect anybody to read through all documentation and config files, especially not for base services and especially not when there is no reason for the user/admin to believe that well known behaviour has changed. Honestly, this is a tempest in a tea pot. Well, that depends on one's PoV. Of course this is just one further little privacy leak. But that's basically everyone's excuse for such issues, and in total all of them make a big issue. Take a thousand tea pots, each with its tempest, and you'll have a real storm. Last but not least,... it isn't so unlikely that resolved *will* become the default, and if only because it's a natural choice. And I see it coming that changing the, then, long standing default, would be refused either. Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Bug#761658: Please do not default to using Google nameservers
Marco, is your position unchanged? Thanks, -- .''`. martin f. krafft madduck@d.o @martinkrafft : :' : proud Debian developer `. `'` http://people.debian.org/~madduck `- Debian - when you have better things to do than fixing systems digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
Bug#761658: Please do not default to using Google nameservers
I think this may even require some broader discussion, perhaps on d-d, about which position Debian has towards privacy. This case here of silently defaulting to a big greedy company who is well-known for being part of the US' world-wide surveillance program is just the tip of an ice-berg. Obviously, I don't say that every program that sends data over the network should need to ask first, especially not when it's obvious that it will do that (e.g. for a browser it's obvious that when you enter some URL, it will send data). But especially those cases where this is not obvious (e.g. several GNOME (and possibly other) programs that send my contact's addresses to gravatar, or when e.g. Firefox extensions like httpseverywhere would default to yes in sending the collected certs to the EFF) this shouldn't be the default and people should properly asked/informed before it happens. This is also especially the case when data is sent to specific companies or organisations (e.g. gravatar) in contrast to a common system (like the DNS when recursing via the root servers). Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Bug#761658: Please do not default to using Google nameservers
also sprach Marco d'Itri m...@linux.it [2015-04-07 22:22 +0200]: is your position unchanged? Yes, since the arguments against this configuration that have been presented so far can be summarized in OMG Google!!!1!. This is not the argument I brought forth. To me, reaching out to a third party to make it work out of the box even without the admin's help is not acceptable. We may work hard to configure our services to provide sensible defaults, but the tendency is still not to turn them on by default. Our MTAs don't have default mail relays. We don't enable AVAHI nor do we install cups-browsed to make things work out of the box. We change upstream software to ensure as much as possible that we don't leak data. We file bug reports against packages linking images from remote web servers to prevent this leakage (cf. e.g. mailman), etc.… In fact, the only software I know that uses defaults for out-of-the-box operation (apart from all the desktop-ware, which is a different beast) is ntpd using pool.ntp.org, but this is a project started by a DD and uses sufficiently random delegation. If you feel the need to further pursue this then please explain in detail the threat model that you are trying to address and how the current default configuration would be worse than other default configurations. In general, Debian has always taken a no-magic-no-frills approach. If you don't configure it, it does not work. In the currently discussed case, your choice means that DNS configuration might be regarded as secondary priority. Meanwhile, some might argue that Google can collect more data and while I also don't want to fuel that beast, more importantly it means that I give Google the power over my DNS lookups, and who knows what that may entail. This is a company that uses JavaScript to disguise click-tracking from your view and Google DNS has not always remained partial to disputes involving political powers. So no, no concrete threat model. But I hope I was able to argue that one is not necessary. The default should be with Debian philoosphy and that has always adhered to the principle of least surprise. In this case, unless DNS is provided or configured, I'd consider it an unpleasant surprise to find out that we are officially routing our users through a commercial, 3rd party entity, whatever they're called. -- .''`. martin f. krafft madduck@d.o @martinkrafft : :' : proud Debian developer `. `'` http://people.debian.org/~madduck `- Debian - when you have better things to do than fixing systems ... alle sätze der logik sagen aber dasselbe. nämlich nichts. -- wittgenstein digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
Bug#761658: Please do not default to using Google nameservers
On Apr 07, martin f krafft madd...@debian.org wrote: is your position unchanged? Yes, since the arguments against this configuration that have been presented so far can be summarized in OMG Google!!!1!. So far the current default looks like a reliable and secure one, 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. If you feel the need to further pursue this then please explain in detail the threat model that you are trying to address and how the current default configuration would be worse than other default configurations. -- ciao, Marco pgpuKytoddR4n.pgp Description: PGP signature
Bug#761658: Please do not default to using Google nameservers
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
Bug#761658: Please do not default to using Google nameservers
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
Bug#761658: Please do not default to using Google nameservers
On Tue, 2015-04-07 at 22:45 +0200, martin f krafft wrote: In fact, the only software I know that uses defaults for out-of-the-box operation (apart from all the desktop-ware, which is a different beast) is ntpd using pool.ntp.org, but this is a project started by a DD and uses sufficiently random delegation. There are several other such cases where pool like defaults are used. E.g. keyservers for OpenPGP and in a sense hardcoding the root name servers in e.g. bind is a similar case. But in both cases I'd say, that this behaviour is fully expected and therefore justified. Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Bug#761658: Please do not default to using Google nameservers
On Apr 07, martin f krafft madd...@debian.org wrote: admin's help is not acceptable. We may work hard to configure our services to provide sensible defaults, but the tendency is still not to turn them on by default. I am not really sure of what this means. Our MTAs don't have default mail relays. At least because there is no such service available. We don't enable AVAHI nor do we install cups-browsed to make things work out of the box. Don't we? Then we probably should do it on desktop systems, since autoconfiguration greatly improves the user experience. We change upstream software to ensure as much as possible that we don't leak data. We file bug reports against DNS queries intrinsecally leak data. Also, your arguments about Debian having no defaults look a bit empty when looking at your original bug report in which you suggest OpenNIC as an acceptable default. So no, no concrete threat model. But I hope I was able to argue that Cool, everything is still OK then. -- ciao, Marco pgp5ULVFhrXG2.pgp Description: PGP signature
Bug#761658: Please do not default to using Google nameservers
Am 07.04.2015 um 22:57 schrieb Marco d'Itri: We don't enable AVAHI nor do we install cups-browsed to make things work out of the box. Don't we? Then we probably should do it on desktop systems, since autoconfiguration greatly improves the user experience. The printer task does actually install both avahi and cups-browsed, for the reasons you mentioned, i.e. make it work out of the box. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#761658: Please do not default to using Google nameservers
also sprach Christoph Anton Mitterer cales...@scientia.net [2015-03-29 07:18 +0200]: So if resolved is used - and I'd guess that's the long term goal - then people would automatically get resolving - always. Even when they have /etc/resolv.conf (possibly intentionally) left empty and AFAIU the manpage, one cannot unset it. I imagine that in a few years, /etc/resolv.conf will be obsolete and no longer used in most cases (cf. xorg.conf, and others). While this is a good development in terms of ease of use, it does put a whole lot more weight on default choices made by upstream and Debian. At the moment, systemd upstream and Debian basically embrace Google and require people who don't want that to do extra work. If that's a direction to go, then shouldn't postfix also be configured by default to relay mail via GMail? -- .''`. martin f. krafft madduck@d.o @martinkrafft : :' : proud Debian developer `. `'` http://people.debian.org/~madduck `- Debian - when you have better things to do than fixing systems digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
Bug#761658: Please do not default to using Google nameservers
Am Sonntag, 29. März 2015, 07:18:43 schrieb Christoph Anton Mitterer: On Sun, 2015-03-29 at 06:55 +0200, Michael Biebl wrote: Am 29.03.2015 um 06:35 schrieb Christoph Anton Mitterer: I'm really not inclined to start another security discussion, since that's already lost cause in Debian... but the appropriate way would be to reopen this bug, solve it so that no data/privacy leakage happen... or perhaps to retitle Debian Windows, I don't really appreciate this tone. You're not really convincing anyone this way only putting people off. The tone wasn't impolite or offensive to anyone,... and that security is just amongst further goals in Debian is simply a matter of fact. And AFAIU the problem of data/privacy leakage isn't just made up, is it? If the system falls back to google nameservers they will now anything one tries to resolve. And $ geoiplookup 8.8.8.8 GeoIP Country Edition: US, United States shows that it won't be only Google who knows ;-) So what exactly is it that you don't like, cause I don't understand it. Seriously, Michael, just because someone didn't start a message with hugs and cookies doesn't mean he meant anything offensive or unfriendly. Or are there already Code of Conflict cases running against me now or Marco because he used the word lunacy on someone else's work o.O I highly appreciate if the default of using google name server if nothing else is configured is removed from Debian´s systemd. I had a similar issue with Debian packaged Wordpress which appears to try to download fonts from Google unless I install a plugin to disable this, which I didn´t yet report. But really, if there is no DNS server configured I expect name resolution to *fail*, instead of the system asking any DNS server of choice by some who was not me. At least unless there is a DNS service that provably doesn´t track and save queries of users of it. As thats near to impossible to prove. And no, I do not want to have to configure the system for basic privacy. I do want this to be the default. This is Debian, no Google Play enabled Android device. So I kindly ask you to remove configuring some DNS server in systemd if the unlikely case none is configured elsewise. User desktops often use DHCP. Then they usually have DNS. And if someone configured network manually, for example for a server VM, please pretty please require that he gives a DNS server by itself. There are even cases where one may not want to have DNS resolution at all. If you want, add a dialog on desktop enviroment no dns server configured with choices like choose one from a list and enter one manually, but don´t do it implicetely. Users are not in control otherwise cause frankly, who would notice that the system would use Google name servers if none a configured? I bet most won´t even notice it. So they are *not* in control. Cause you can only be in control of what you *know*. I didn´t notice Wordpress accessing Google servers unless I installed Iceweasel request policy plugin. Thus I didn´t just sacrifice the privacy of myself, but also of my users *without* knowing so. I was very angry as I found out which remembers me to report a bug. I didn´t at that time as I even feared a harsh respone. If a systemd based system is used on a misconfigured router it may leak the privacy of any users behind it. I hope this gives a clear reasoning. Frankly I do not understand why this default has not already been removed long ago. Whats the case for *having* this as a default? Some minor convenience in the case someone messes up network configuration by not providing a DNS server? Just that it is in systemd upstream does not mean that it is good to have. Ciao, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 signature.asc Description: This is a digitally signed message part.
Bug#761658: Please do not default to using Google nameservers
Am Sonntag, 29. März 2015, 08:28:20 schrieb martin f krafft: also sprach Christoph Anton Mitterer cales...@scientia.net [2015-03-29 07:18 +0200]: So if resolved is used - and I'd guess that's the long term goal - then people would automatically get resolving - always. Even when they have /etc/resolv.conf (possibly intentionally) left empty and AFAIU the manpage, one cannot unset it. I imagine that in a few years, /etc/resolv.conf will be obsolete and no longer used in most cases (cf. xorg.conf, and others). While this is a good development in terms of ease of use, it does put a whole lot more weight on default choices made by upstream and Debian. At the moment, systemd upstream and Debian basically embrace Google and require people who don't want that to do extra work. If that's a direction to go, then shouldn't postfix also be configured by default to relay mail via GMail? Frankly, nope. For the reasons I explained in my other post to this bug report. I understand better and better why I deleted my Google account some time ago. -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 signature.asc Description: This is a digitally signed message part.
Bug#761658: Please do not default to using Google nameservers
On Sun, 29 Mar 2015 05:57:22 +0200 m...@linux.it (Marco d'Itri) wrote: This default is not used as long as a resolver has been configured by the system administrator or provided by DHCP, and I see no value in allocating development time to break cases which currently work by removing support for a default. People do not need one if they do not want to configure one. Since the Google resolvers are a very reliable widely anycasted service which third parties are encouraged to use they actually look like a sane fail-safe default, hence I am closing this bug. The DNS query traffic to Google resolvers may be hijacked in some contries, or just blocked. For people who really need a default one, it's may be a better choice to use the default gateway as the default DNS resolver. Or we may patch systemd- resolved to scan the local network to find a usable DNS server. It's funny to see systemd-resolved.
Bug#761658: Please do not default to using Google nameservers
On Sun, 2015-03-29 at 12:47 +0200, Marco d'Itri wrote: So far, it is. If you still want to argue about this (which I something that I strongly recommend against!), then you should explain in detail the threat model that you are trying to address and how the current configuration would be worse than other configurations. The original reporter, I and some others did so before. I don't see a point in repeating an explanation of the same thread model over and over again. Either it's as it is, or the documentation is at least misleading. $ geoiplookup 8.8.8.8 GeoIP Country Edition: US, United States traceroutes from multiple non-US locations may surprise you. $ traceroute 8.8.8.8 traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets 1 [snip snap] 2 [snip snap] 3 [snip snap] 4 93.104.240.55 (93.104.240.55) 24.388 ms 24.773 ms 25.538 ms 5 209.85.253.113 (209.85.253.113) 25.002 ms 64.233.175.121 (64.233.175.121) 25.131 ms 209.85.252.215 (209.85.252.215) 25.808 ms 6 google-public-dns-a.google.com (8.8.8.8) 25.623 ms 15.634 ms 15.724 ms calestyo@heisenberg:~$ geoiplookup 209.85.253.113 GeoIP Country Edition: US, United States calestyo@heisenberg:~$ geoiplookup 64.233.175.121 GeoIP Country Edition: US, United States calestyo@heisenberg:~$ geoiplookup 209.85.252.215 GeoIP Country Edition: US, United States Nope, not really a surprise. And I'm Germany based. Unless all these hops would be anycasted, traffic goes into the US. And even if not, there is nothing that guarantees that this would never change, and even if, it's well known that subsidiaries of US companies are forced by US law to obey to US governmental agencies. I argue that alternative DNS roots are firmly in the camp of net.kooks, and there is more than enough history to support this. Were you around at the time of the newdom mailing list? Fun times... Be careful of who you choose to associate with, because you will be judged by your peers for it. I haven't said that *I* would endorse the switch to OpenNIC, have I? Quite the contrary actually. This was just an example that Michael should try to stay calm an not open a CoC case just because someone doesn't share his views. I did, in my reply. Short summary: have a resolv.conf file or use DHCP. As stated by the others, this is both non-obvious and non-standards behaviour, i.e. explicitly having to opt-out of default-Google-name-resolution (and potentially/likely surveillance/tracking). Now I'm for sure not a traditionalist who wants to keep things as they are just per se, but here I see only disadvantages in changing the way it used to be. No nameservers configured - no resolution. Done. What comes next? A google or aol account that's automatically set up with Debian installation? Which of course has no direct disadvantage to the user. Still it would be wrong. Then maybe you should work in the IETF to establish either: - well know IP addresses which will provide recursive DNS service (this may even work now that we have DNSSEC) Such a thing doesn't exist, because it's not necessary + would be bad design. For autoconfiguration of systems (including the resolvers) we already have plenty of mechanisms. - a best practice of running a caching resolver on every end user system (I highly doubt that this would be considered a good idea) I don't see how this affects this topic? But apart from that, it will probably be the future, at least when people want locally verified DNSSEC resolution. Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Bug#761658: Please do not default to using Google nameservers
On Mar 29, Christoph Anton Mitterer cales...@scientia.net wrote: And AFAIU the problem of data/privacy leakage isn't just made up, is it? So far, it is. If you still want to argue about this (which I something that I strongly recommend against!), then you should explain in detail the threat model that you are trying to address and how the current configuration would be worse than other configurations. $ geoiplookup 8.8.8.8 GeoIP Country Edition: US, United States traceroutes from multiple non-US locations may surprise you. Or are there already Code of Conflict cases running against me now or Marco because he used the word lunacy on someone else's work o.O I argue that alternative DNS roots are firmly in the camp of net.kooks, and there is more than enough history to support this. Were you around at the time of the newdom mailing list? Fun times... Be careful of who you choose to associate with, because you will be judged by your peers for it. Marco told you specifically, how you can configure this explicitly. Uhm? I just accidentally stumbled over this bug and I don't think he has told me anything in specific. I did, in my reply. Short summary: have a resolv.conf file or use DHCP. IMO, OpenNIC or anything else would have the same issues than Google: Then maybe you should work in the IETF to establish either: - well know IP addresses which will provide recursive DNS service (this may even work now that we have DNSSEC) - a best practice of running a caching resolver on every end user system (I highly doubt that this would be considered a good idea) -- ciao, Marco pgpk81c2aMlkL.pgp Description: PGP signature
Bug#761658: Please do not default to using Google nameservers
btw: Letting people use unknowingly a specific nameserver may have also further consequences than just privacy leakage. Since e.g. the Google nameservers are well known to allow people to circumvent DNS blocks, they're quite likely under special observation by governmental agencies in autocratic countries like China, Turkey, etc. where internet censorship is daily practise. So if you use these services you may actually get into troubles... and I guess we don't make Debian just for people in safe countries. If you don't see the thread in the above schema, take the following comparable example: According to the US secretary of justice (IIRC), Tor is just used by criminals and paedophiles (o.O), and we all know since Snowden that people using Tor are specially flaged and that it has already happened that such people were taken into custody when crossing the US border. So we should perhaps not make Tor the default and maybe wikileaks.org the default homepage in browsers. Neither should we give people a Tor config that relays per default, cause it may get them really into troubles even in Europe. And it's not that I wouldn't support the goals of things like Tor - but the decision what to use and what not should be left at the user/admin in the form of a deliberate decision, and not an opt-out decsision. Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Bug#761658: Please do not default to using Google nameservers
On Sun, 2015-03-29 at 05:57 +0200, Marco d'Itri wrote: From resolved.conf(5): Any per-interface DNS servers obtained from systemd-networkd.service(8) take precedence over this setting, as do any servers set via DNS= above or /etc/resolv.conf. This setting is hence only used if no other DNS server information is known. I would like to propose that we either provide no default fallback, or chose to support OpenNIC that way. This default is not used as long as a resolver has been configured by the system administrator or provided by DHCP, and I see no value in allocating development time to break cases which currently work by removing support for a default. Wouldn't it be then the naturally expected result that DNS recursion simply fails and not built-in resolver of some data and money greedy company is used? If I haven't DNS configured, I probably don't want it to happen - and if I do, then I will very quickly notice that it doesn't work and can easily correct it. The amount of privacy leakage that sums up these days in Linux and also Debian is really disturbing. The masses whine about mass surveillance and we have nothing better to do than just making live of spy and tracking companies as easy as possible. I'm probably used to, that all kinds of GNOME programs leak my peers to gravatar (and even that the respective upstreams are quite hostile, when one tells them they have privacy issues)... but now we start such things even at the lowest system level? Simply disturbing. Since the Google resolvers are a very reliable widely anycasted service which third parties are encouraged to use they actually look like a sane fail-safe default, hence I am closing this bug. Well and I'm sure the NSA is best in storing data safely - nevertheless I wouldn't want them to provide me their friendly backup services. I'm really not inclined to start another security discussion, since that's already lost cause in Debian... but the appropriate way would be to reopen this bug, solve it so that no data/privacy leakage happen... or perhaps to retitle Debian Windows, since apparently we're at the best way to become a system where everything works with many colours out of the box, but no longer under control or possessed by the user/admin. Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Bug#761658: Please do not default to using Google nameservers
Am 29.03.2015 um 06:35 schrieb Christoph Anton Mitterer: I'm really not inclined to start another security discussion, since that's already lost cause in Debian... but the appropriate way would be to reopen this bug, solve it so that no data/privacy leakage happen... or perhaps to retitle Debian Windows, I don't really appreciate this tone. You're not really convincing anyone this way only putting people off. since apparently we're at the best way to become a system where everything works with many colours out of the box, but no longer under control or possessed by the user/admin. Marco told you specifically, how you can configure this explicitly. So how exactly are you no longer in control? Michae -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#761658: Please do not default to using Google nameservers
On Sun, 2015-03-29 at 06:55 +0200, Michael Biebl wrote: Am 29.03.2015 um 06:35 schrieb Christoph Anton Mitterer: I'm really not inclined to start another security discussion, since that's already lost cause in Debian... but the appropriate way would be to reopen this bug, solve it so that no data/privacy leakage happen... or perhaps to retitle Debian Windows, I don't really appreciate this tone. You're not really convincing anyone this way only putting people off. The tone wasn't impolite or offensive to anyone,... and that security is just amongst further goals in Debian is simply a matter of fact. And AFAIU the problem of data/privacy leakage isn't just made up, is it? If the system falls back to google nameservers they will now anything one tries to resolve. And $ geoiplookup 8.8.8.8 GeoIP Country Edition: US, United States shows that it won't be only Google who knows ;-) So what exactly is it that you don't like, cause I don't understand it. Seriously, Michael, just because someone didn't start a message with hugs and cookies doesn't mean he meant anything offensive or unfriendly. Or are there already Code of Conflict cases running against me now or Marco because he used the word lunacy on someone else's work o.O Marco told you specifically, how you can configure this explicitly. Uhm? I just accidentally stumbled over this bug and I don't think he has told me anything in specific. So how exactly are you no longer in control? Maybe I just got it wrong and this is a non-issue: My understanding was that resolved defaults to DNS=8.8.8.8 8.8.4.4 2001:4860:4860:: 2001:4860:4860::8844 Right? So if resolved is used - and I'd guess that's the long term goal - then people would automatically get resolving - always. Even when they have /etc/resolv.conf (possibly intentionally) left empty and AFAIU the manpage, one cannot unset it. If this is all the case, than it's asas Martin has quite correctly identified in the beginning: We shouldn't provide a default fallback. IMO, OpenNIC or anything else would have the same issues than Google: - it's a privacy leak - it specially blesses a single company/organisation as being the nameserver provider for Debian, and I think we should be neutral here Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Bug#761658: Please do not default to using Google nameservers
Package: systemd Version: 215-3 Severity: wishlist From a cursory look over the sources, I am led to believe that resolved defaults to using Google nameservers. I would like to propose that we either provide no default fallback, or chose to support OpenNIC that way. Thank you for your consideration. -- Package-specific info: -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16-trunk-amd64 (SMP w/4 CPU cores) Locale: LANG=en_NZ, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages systemd depends on: ii acl 2.2.52-2 ii adduser 3.113+nmu3 ii initscripts 2.88dsf-53.4 ii libacl1 2.2.52-2 ii libaudit1 1:2.4-1 ii libblkid1 2.20.1-5.8 ii libc6 2.19-11 ii libcap2 1:2.24-4 ii libcap2-bin 1:2.24-4 ii libcryptsetup4 2:1.6.6-1 ii libgcrypt11 1.5.4-3 ii libkmod218-1 ii liblzma55.1.1alpha+20120614-2 ii libpam0g1.1.8-3.1 ii libselinux1 2.3-2 ii libsystemd0 215-3 ii sysv-rc 2.88dsf-53.4 ii udev208-8 ii util-linux 2.20.1-5.8 Versions of packages systemd recommends: ii dbus1.8.6-2 ii libpam-systemd 215-3 Versions of packages systemd suggests: pn systemd-ui none -- no debconf information -- .''`. martin f. krafft madduck@d.o @martinkrafft : :' : proud Debian developer `. `'` http://people.debian.org/~madduck `- Debian - when you have better things to do than fixing systems digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
Bug#761658: Please do not default to using Google nameservers
On Sep 15, martin f krafft madd...@debian.org wrote: I would like to propose that we either provide no default fallback, or chose to support OpenNIC that way. If there has to be a default and if it has to be different from the current one, then I am violently opposed to even consider associating Debian with that OpenNIC lunacy. -- ciao, Marco signature.asc Description: Digital signature
