Debian Bug report logs - #761658
Please do not default to using Google nameservers

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: martin f krafft <madduck@debian.org>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: Please do not default to using Google nameservers

Date: Mon, 15 Sep 2014 16:08:25 +0200

[Message part 1 (text/plain, inline)]

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  libkmod2        18-1
ii  liblzma5        5.1.1alpha+20120614-2
ii  libpam0g        1.1.8-3.1
ii  libselinux1     2.3-2
ii  libsystemd0     215-3
ii  sysv-rc         2.88dsf-53.4
ii  udev            208-8
ii  util-linux      2.20.1-5.8

Versions of packages systemd recommends:
ii  dbus            1.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 (application/pgp-signature, inline)]

Message #10 received at 761658@bugs.debian.org (full text, mbox, reply):

From: md@Linux.IT (Marco d'Itri)

To: martin f krafft <madduck@debian.org>, 761658@bugs.debian.org

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

Date: Mon, 15 Sep 2014 17:08:17 +0200

[Message part 1 (text/plain, inline)]

On Sep 15, martin f krafft <madduck@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 (application/pgp-signature, inline)]

Message #15 received at 761658-done@bugs.debian.org (full text, mbox, reply):

From: md@Linux.IT (Marco d'Itri)

To: martin f krafft <madduck@debian.org>, 761658-done@bugs.debian.org

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

Date: Sun, 29 Mar 2015 05:57:22 +0200

[Message part 1 (text/plain, inline)]

Control: tag -1 wontfix

On Sep 15, martin f krafft <madduck@debian.org> wrote:

> From a cursory look over the sources, I am led to believe that
> resolved defaults to using Google nameservers.
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.
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.

-- 
ciao,
Marco

[Message part 2 (application/pgp-signature, inline)]

Message #20 received at 761658@bugs.debian.org (full text, mbox, reply):

From: Christoph Anton Mitterer <calestyo@scientia.net>

To: 761658@bugs.debian.org

Cc: martin f krafft <madduck@debian.org>

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

Date: Sun, 29 Mar 2015 06:35:12 +0200

[Message part 1 (text/plain, inline)]

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 (application/x-pkcs7-signature, attachment)]

Message #25 received at 761658@bugs.debian.org (full text, mbox, reply):

From: Michael Biebl <biebl@debian.org>

To: Christoph Anton Mitterer <calestyo@scientia.net>, 761658@bugs.debian.org

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

Date: Sun, 29 Mar 2015 06:55:56 +0200

[Message part 1 (text/plain, inline)]

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 (application/pgp-signature, attachment)]

Message #30 received at 761658@bugs.debian.org (full text, mbox, reply):

From: Christoph Anton Mitterer <calestyo@scientia.net>

To: 761658@bugs.debian.org

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

Date: Sun, 29 Mar 2015 07:18:43 +0200

[Message part 1 (text/plain, inline)]

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::8888 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 (application/x-pkcs7-signature, attachment)]

Message #35 received at 761658@bugs.debian.org (full text, mbox, reply):

From: martin f krafft <madduck@debian.org>

To: 761658@bugs.debian.org

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

Date: Sun, 29 Mar 2015 08:28:20 +0200

[Message part 1 (text/plain, inline)]

also sprach Christoph Anton Mitterer <calestyo@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 (application/pgp-signature, inline)]

Message #40 received at 761658@bugs.debian.org (full text, mbox, reply):

From: Martin Steigerwald <martin@lichtvoll.de>

To: 761658@bugs.debian.org, Christoph Anton Mitterer <calestyo@scientia.net>

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

Date: Sun, 29 Mar 2015 11:59:10 +0200

[Message part 1 (text/plain, inline)]

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 (application/pgp-signature, inline)]

Message #45 received at 761658@bugs.debian.org (full text, mbox, reply):

From: Martin Steigerwald <martin@lichtvoll.de>

To: 761658@bugs.debian.org, martin f krafft <madduck@debian.org>

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

Date: Sun, 29 Mar 2015 12:01:10 +0200

[Message part 1 (text/plain, inline)]

Am Sonntag, 29. März 2015, 08:28:20 schrieb martin f krafft:
> also sprach Christoph Anton Mitterer <calestyo@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 (application/pgp-signature, inline)]

Message #50 received at 761658@bugs.debian.org (full text, mbox, reply):

From: 张敬强 <godfrey.public@gmail.com>

To: 761658@bugs.debian.org

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

Date: Sun, 29 Mar 2015 19:05:54 +0800

[Message part 1 (text/plain, inline)]

On Sun, 29 Mar 2015 05:57:22 +0200 md@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.

[Message part 2 (text/html, inline)]

Message #55 received at 761658@bugs.debian.org (full text, mbox, reply):

From: md@Linux.IT (Marco d'Itri)

To: Christoph Anton Mitterer <calestyo@scientia.net>, 761658@bugs.debian.org

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

Date: Sun, 29 Mar 2015 12:47:51 +0200

[Message part 1 (text/plain, inline)]

On Mar 29, Christoph Anton Mitterer <calestyo@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

[Message part 2 (application/pgp-signature, inline)]

Message #60 received at 761658@bugs.debian.org (full text, mbox, reply):

From: Christoph Anton Mitterer <calestyo@scientia.net>

To: 761658@bugs.debian.org

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

Date: Sun, 29 Mar 2015 22:03:24 +0200

[Message part 1 (text/plain, inline)]

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 (application/x-pkcs7-signature, attachment)]

Message #65 received at 761658@bugs.debian.org (full text, mbox, reply):

From: Christoph Anton Mitterer <calestyo@scientia.net>

To: 761658@bugs.debian.org

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

Date: Sun, 29 Mar 2015 22:34:12 +0200

[Message part 1 (text/plain, inline)]

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 (application/x-pkcs7-signature, attachment)]

Message #70 received at 761658@bugs.debian.org (full text, mbox, reply):

From: Adam Borowski <kilobyte@angband.pl>

To: 761658@bugs.debian.org

Subject: it's a security hole

Date: Mon, 30 Mar 2015 01:56:08 +0200

How come this issue isn't RC?

You're sending every DNS resolution attempt, and thus effectively the
metadata on almost any TCP/IP connection, to a company well-known to
collect and use this kind of data.

This is worse than, say, Ubuntu's Unity Lens spyware.

Message #75 received at 761658@bugs.debian.org (full text, mbox, reply):

From: Carlo Stemberger <carlo.stemberger@gmail.com>

To: 761658@bugs.debian.org, 761658-subscribe@bugs.debian.org

Subject: Please reopen this bug report

Date: Mon, 30 Mar 2015 02:31:12 +0200

[Message part 1 (text/plain, inline)]

Hi,
I agree: no nameserver → no resolution.

Please reopen this bug report.

Thank you!

Carlo

[Message part 2 (text/html, inline)]

Message #80 received at 761658@bugs.debian.org (full text, mbox, reply):

From: Ferdinando Bassi <bassi@easyteam.org>

To: "761658@bugs.debian.org" <761658@bugs.debian.org>

Subject: Re: Please reopen this bug report

Date: Mon, 30 Mar 2015 19:59:34 +0000

Hi all,
I agree too.
No nameserver and no resolution.
That should be the default.

When I connect by DHCP, I already get the DNS the sysadmin configured to be used.
When I connect by Manual IP I just setup the DNS I want.

There is no need to have a default DNS configuration, as there is no need to have a default printer, or a default SMTP.

Ciao,
Ferdinando


On Mon, 30 Mar 2015 02:31:12 +0200 Carlo Stemberger <carlo.stemberger@gmail.com> wrote: 
> Hi, 
> I agree: no nameserver → no resolution. 
> 
> Please reopen this bug report. 
> 
> Thank you! 
> 
> Carlo 

Message #85 received at 761658@bugs.debian.org (full text, mbox, reply):

From: martin f krafft <madduck@debian.org>

To: 761658@bugs.debian.org

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

Date: Tue, 7 Apr 2015 20:45:59 +0200

[Message part 1 (text/plain, inline)]

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 (application/pgp-signature, inline)]

Message #90 received at 761658@bugs.debian.org (full text, mbox, reply):

From: Christoph Anton Mitterer <calestyo@scientia.net>

To: 761658@bugs.debian.org

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

Date: Tue, 07 Apr 2015 21:11:49 +0200

[Message part 1 (text/plain, inline)]

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 (application/x-pkcs7-signature, attachment)]

Message #95 received at 761658@bugs.debian.org (full text, mbox, reply):

From: md@Linux.IT (Marco d'Itri)

To: martin f krafft <madduck@debian.org>, 761658@bugs.debian.org

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

Date: Tue, 7 Apr 2015 22:22:20 +0200

[Message part 1 (text/plain, inline)]

On Apr 07, martin f krafft <madduck@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

[Message part 2 (application/pgp-signature, inline)]

Message #100 received at 761658@bugs.debian.org (full text, mbox, reply):

From: Christoph Anton Mitterer <calestyo@scientia.net>

To: 761658@bugs.debian.org

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

Date: Tue, 07 Apr 2015 22:43:19 +0200

[Message part 1 (text/plain, inline)]

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 (application/x-pkcs7-signature, attachment)]

Message #105 received at 761658@bugs.debian.org (full text, mbox, reply):

From: martin f krafft <madduck@debian.org>

To: Marco d'Itri <md@Linux.IT>

Cc: 761658@bugs.debian.org

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

Date: Tue, 7 Apr 2015 22:45:16 +0200

[Message part 1 (text/plain, inline)]

also sprach Marco d'Itri <md@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 (application/pgp-signature, inline)]

Message #110 received at 761658@bugs.debian.org (full text, mbox, reply):

From: Christoph Anton Mitterer <calestyo@scientia.net>

To: 761658@bugs.debian.org

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

Date: Tue, 07 Apr 2015 22:56:17 +0200

[Message part 1 (text/plain, inline)]

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 (application/x-pkcs7-signature, attachment)]

Message #115 received at 761658@bugs.debian.org (full text, mbox, reply):

From: Marco d'Itri <md@Linux.IT>

To: martin f krafft <madduck@debian.org>

Cc: 761658@bugs.debian.org

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

Date: Tue, 7 Apr 2015 22:57:59 +0200

[Message part 1 (text/plain, inline)]

On Apr 07, martin f krafft <madduck@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

[Message part 2 (application/pgp-signature, inline)]

Message #120 received at 761658@bugs.debian.org (full text, mbox, reply):

From: Michael Biebl <biebl@debian.org>

To: Marco d'Itri <md@Linux.IT>, 761658@bugs.debian.org, martin f krafft <madduck@debian.org>

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

Date: Tue, 07 Apr 2015 23:13:05 +0200

[Message part 1 (text/plain, inline)]

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 (application/pgp-signature, attachment)]

Message #125 received at 761658@bugs.debian.org (full text, mbox, reply):

From: Christoph Anton Mitterer <calestyo@scientia.net>

To: 761658@bugs.debian.org

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

Date: Tue, 07 Apr 2015 23:26:46 +0200

[Message part 1 (text/plain, inline)]

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 (application/x-pkcs7-signature, attachment)]

Message #130 received at 761658@bugs.debian.org (full text, mbox, reply):

From: martin f krafft <madduck@debian.org>

To: Marco d'Itri <md@Linux.IT>, Michael Biebl <biebl@debian.org>

Cc: 761658@bugs.debian.org

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

Date: Wed, 8 Apr 2015 09:55:03 +0200

[Message part 1 (text/plain, inline)]

also sprach Marco d'Itri <md@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 <biebl@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 (application/pgp-signature, inline)]

Message #135 received at 761658@bugs.debian.org (full text, mbox, reply):

From: Michael Biebl <biebl@debian.org>

To: martin f krafft <madduck@debian.org>, 761658@bugs.debian.org

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

Date: Wed, 08 Apr 2015 10:45:12 +0200

[Message part 1 (text/plain, inline)]

Am 08.04.2015 um 09:55 schrieb martin f krafft:
> also sprach Marco d'Itri <md@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 (application/pgp-signature, attachment)]

Message #140 received at 761658@bugs.debian.org (full text, mbox, reply):

From: martin f krafft <madduck@debian.org>

To: Michael Biebl <biebl@debian.org>

Cc: 761658@bugs.debian.org

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

Date: Wed, 8 Apr 2015 11:33:29 +0200

[Message part 1 (text/plain, inline)]

also sprach Michael Biebl <biebl@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 (application/pgp-signature, inline)]

Message #145 received at 761658@bugs.debian.org (full text, mbox, reply):

From: Michael Biebl <biebl@debian.org>

To: martin f krafft <madduck@debian.org>

Cc: 761658@bugs.debian.org

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

Date: Wed, 08 Apr 2015 11:44:26 +0200

[Message part 1 (text/plain, inline)]

Am 08.04.2015 um 11:33 schrieb martin f krafft:
> also sprach Michael Biebl <biebl@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 (application/pgp-signature, attachment)]

Message #150 received at 761658@bugs.debian.org (full text, mbox, reply):

From: martin f krafft <madduck@debian.org>

To: Michael Biebl <biebl@debian.org>

Cc: 761658@bugs.debian.org

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

Date: Wed, 8 Apr 2015 11:54:15 +0200

[Message part 1 (text/plain, inline)]

also sprach Michael Biebl <biebl@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 (application/pgp-signature, inline)]

Message #155 received at 761658@bugs.debian.org (full text, mbox, reply):

From: Christoph Anton Mitterer <calestyo@scientia.net>

To: 761658@bugs.debian.org

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

Date: Wed, 08 Apr 2015 15:03:11 +0200

[Message part 1 (text/plain, inline)]

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 (application/x-pkcs7-signature, attachment)]

Message #166 received at 761658@bugs.debian.org (full text, mbox, reply):

From: Norbert Preining <norbert@preining.info>

To: 761658@bugs.debian.org

Subject: urgency of a fix before stretch

Date: Fri, 2 Jun 2017 23:32:43 +0900

Dear maintainers,

leaking information, whatsoever, is not acceptable in Debian, and against
policy, at least lintian errors out on many occasions with
	privacy-foobar*
errors.

Setting the default servers to Google is not acceptable. 

Ignoring this fact with the explanation that one can *disable* it is
not sufficient. Reason: *Every* leak can be disabled by unplugging the
network cable. 

This is not a solution.

I am planning to upload an NMU fixing this issue to DELAY3 and hope that
release managers allow this fix into stretch.

All the best

Norbert

--
PREINING Norbert                               http://www.preining.info
Accelia Inc.     +    JAIST     +    TeX Live     +    Debian Developer
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Message #171 received at 761658@bugs.debian.org (full text, mbox, reply):

From: Michael Biebl <biebl@debian.org>

To: Norbert Preining <norbert@preining.info>, 761658@bugs.debian.org

Subject: Re: Bug#761658: urgency of a fix before stretch

Date: Fri, 2 Jun 2017 16:38:59 +0200

[Message part 1 (text/plain, inline)]

Am 02.06.2017 um 16:32 schrieb Norbert Preining:
> Dear maintainers,
> 
> leaking information, whatsoever, is not acceptable in Debian, and against
> policy, at least lintian errors out on many occasions with
> 	privacy-foobar*
> errors.
> 
> Setting the default servers to Google is not acceptable. 
> 
> Ignoring this fact with the explanation that one can *disable* it is
> not sufficient. Reason: *Every* leak can be disabled by unplugging the
> network cable. 
> 
> This is not a solution.
> 
> I am planning to upload an NMU fixing this issue to DELAY3 and hope that
> release managers allow this fix into stretch.

Your reasoning is flawed. The Google DNS servers are not set as default.
Neither is resolved enabled by default.

So I object to your hostile NMU.



-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

[signature.asc (application/pgp-signature, attachment)]

Message #176 received at 761658@bugs.debian.org (full text, mbox, reply):

From: Norbert Preining <norbert@preining.info>

To: Michael Biebl <biebl@debian.org>

Cc: 761658@bugs.debian.org

Subject: Re: Bug#761658: urgency of a fix before stretch

Date: Fri, 2 Jun 2017 23:46:36 +0900

> Your reasoning is flawed. The Google DNS servers are not set as default.

AC_ARG_WITH(dns-servers,
        AS_HELP_STRING([--with-dns-servers=DNSSERVERS],
                [Space-separated list of default DNS servers]),
        [DNS_SERVERS="$withval"],
        [DNS_SERVERS="8.8.8.8 8.8.4.4 2001:4860:4860::8888 2001:4860:4860::8844"])

and I don't see any usage of --with-dns-servers ?

Please explain?

Norbert

--
PREINING Norbert                               http://www.preining.info
Accelia Inc.     +    JAIST     +    TeX Live     +    Debian Developer
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Message #181 received at 761658@bugs.debian.org (full text, mbox, reply):

From: Michael Biebl <biebl@debian.org>

To: Norbert Preining <norbert@preining.info>

Cc: 761658@bugs.debian.org

Subject: Re: Bug#761658: urgency of a fix before stretch

Date: Fri, 2 Jun 2017 16:54:32 +0200

[Message part 1 (text/plain, inline)]

Am 02.06.2017 um 16:46 schrieb Norbert Preining:
>> Your reasoning is flawed. The Google DNS servers are not set as default.
> 
> AC_ARG_WITH(dns-servers,
>         AS_HELP_STRING([--with-dns-servers=DNSSERVERS],
>                 [Space-separated list of default DNS servers]),
>         [DNS_SERVERS="$withval"],
>         [DNS_SERVERS="8.8.8.8 8.8.4.4 2001:4860:4860::8888 2001:4860:4860::8844"])
> 
> and I don't see any usage of --with-dns-servers ?
> 
> Please explain?

You're the one who needs to explain a hostile NMU.
Do you actually know what this is about?


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

[signature.asc (application/pgp-signature, attachment)]

Message #186 received at 761658@bugs.debian.org (full text, mbox, reply):

From: md@Linux.IT (Marco d'Itri)

To: Norbert Preining <norbert@preining.info>, 761658@bugs.debian.org

Subject: Re: Bug#761658: urgency of a fix before stretch

Date: Fri, 2 Jun 2017 22:49:39 +0200

[Message part 1 (text/plain, inline)]

On Jun 02, Norbert Preining <norbert@preining.info> wrote:

> I am planning to upload an NMU fixing this issue to DELAY3 and hope that
> release managers allow this fix into stretch.
You cannot do a NMU just because the maintainers of a package disagree 
with you.

As one of the systemd maintainers I am explicitly and publicly 
requesting that you do not introduce this unwanted change.

-- 
ciao,
Marco

[signature.asc (application/pgp-signature, inline)]

Message #191 received at 761658@bugs.debian.org (full text, mbox, reply):

From: Norbert Preining <norbert@preining.info>

To: md@Linux.IT,761658@bugs.debian.org

Subject: Re: Bug#761658: urgency of a fix before stretch

Date: Sat, 03 Jun 2017 07:12:02 +0900

[Message part 1 (text/plain, inline)]

Good morning,

>As one of the systemd maintainers I am explicitly and publicly 
>requesting that you do not introduce this unwanted change.

Then how are you planning to deal with this serious bug after years of inactivity?

Norbert


On June 3, 2017 5:49:39 AM GMT+09:00, md@Linux.IT wrote:
>On Jun 02, Norbert Preining <norbert@preining.info> wrote:
>
>> I am planning to upload an NMU fixing this issue to DELAY3 and hope
>that
>> release managers allow this fix into stretch.
>You cannot do a NMU just because the maintainers of a package disagree 
>with you.
>


--
PREINING Norbert + TeX Live & Debian Developer + http://www.preining.info
GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

[Message part 2 (text/html, inline)]

Message #196 received at 761658@bugs.debian.org (full text, mbox, reply):

From: martin f krafft <madduck@debian.org>

To: Norbert Preining <norbert@preining.info>, 761658@bugs.debian.org

Cc: md@Linux.IT

Subject: Re: Bug#761658: urgency of a fix before stretch

Date: Sat, 3 Jun 2017 08:12:14 +0200

[Message part 1 (text/plain, inline)]

also sprach Norbert Preining <norbert@preining.info> [2017-06-03 00:12 +0200]:
> Then how are you planning to deal with this serious bug after
> years of inactivity?

Sounds like it might need ctte attention.

-- 
 .''`.   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 (application/pgp-signature, inline)]

Message #201 received at 761658@bugs.debian.org (full text, mbox, reply):

From: Marco d'Itri <md@Linux.IT>

To: Norbert Preining <norbert@preining.info>

Cc: 761658@bugs.debian.org

Subject: Re: Bug#761658: urgency of a fix before stretch

Date: Sat, 3 Jun 2017 00:13:58 +0200

[Message part 1 (text/plain, inline)]

On Jun 03, Norbert Preining <norbert@preining.info> wrote:

> >As one of the systemd maintainers I am explicitly and publicly 
> >requesting that you do not introduce this unwanted change.
> Then how are you planning to deal with this serious bug after years of inactivity?
I think that I have already expressed clearly my position.

-- 
ciao,
Marco

[signature.asc (application/pgp-signature, inline)]

Message #206 received at 761658@bugs.debian.org (full text, mbox, reply):

From: Martin Steigerwald <martin@lichtvoll.de>

To: 761658@bugs.debian.org, martin f krafft <madduck@debian.org>

Cc: Norbert Preining <norbert@preining.info>, md@linux.it

Subject: Re: Bug#761658: urgency of a fix before stretch

Date: Sat, 03 Jun 2017 16:54:36 +0200

martin f krafft - 03.06.17, 08:12:
> also sprach Norbert Preining <norbert@preining.info> [2017-06-03 00:12 
+0200]:
> > Then how are you planning to deal with this serious bug after
> > years of inactivity?
> 
> Sounds like it might need ctte attention.

I agree to that, since a discussion between the people advocating the removal 
of google DNS servers as a default for resolved and current systemd debian 
package maintainers Michael and Marco is going in circles and does not seem to 
lead to any outcome that would resolve the conflict.

Thanks,
-- 
Martin

Message #211 received at 761658@bugs.debian.org (full text, mbox, reply):

From: benaryorg <binary@benary.org>

To: 761658@bugs.debian.org

Subject: reliably disable DNS resolving

Date: Wed, 14 Jun 2017 19:49:30 +0200

[Message part 1 (text/plain, inline)]

As this is about the default nameservers to be used when there is
nothing else configured, how would I disable DNS resolution then?

Because I see that this is a technical issue for which there is no
solution mentioned in this bugreport yet.
At least for settling this part of the issue can you please present a
solution that is equal to not configuring any hosts on a system which
does not have it's defaults set?

[signature.asc (application/pgp-signature, attachment)]

Message #216 received at 761658@bugs.debian.org (full text, mbox, reply):

From: Michael Biebl <biebl@debian.org>

To: benaryorg <binary@benary.org>, 761658@bugs.debian.org

Subject: Re: Bug#761658: reliably disable DNS resolving

Date: Wed, 14 Jun 2017 20:48:59 +0200

[Message part 1 (text/plain, inline)]

Hi

Am 14.06.2017 um 19:49 schrieb benaryorg:
> As this is about the default nameservers to be used when there is
> nothing else configured, how would I disable DNS resolution then?

First of all, systemd-resolved is not used and enabled by default.
If you actually do use systemd-resolved, disabling the
fallback DNS server(s) is trivial.

Either edit /etc/systemd/resolved.conf and set 
FallbackDNS=

or create a drop-in snippet like this:
mkdir /etc/systemd/resolved.conf.d/
echo -e "[Resolve]\nFallbackDNS=" > /etc/systemd/resolved.conf.d/no-fallback.conf

Then run systemctl restart systemd-resolved.service.

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

[signature.asc (application/pgp-signature, attachment)]

Send a report that this bug log contains spam.