Discussion:
Bug#761658: Please do not default to using Google nameservers
(too old to reply)
martin f krafft
2014-09-15 14:08:25 UTC
Permalink
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 <***@d.o> @martinkrafft
: :' : proud Debian developer
`. `'` http://people.debian.org/~madduck
`- Debian - when you have better things to do than fixing systems
Marco d'Itri
2014-09-15 15:08:17 UTC
Permalink
Post by martin f krafft
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
Christoph Anton Mitterer
2015-03-29 04:35:12 UTC
Permalink
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.
Post by martin f krafft
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.
Michael Biebl
2015-03-29 04:55:56 UTC
Permalink
Post by 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
Post by Christoph Anton Mitterer
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?
Christoph Anton Mitterer
2015-03-29 05:18:43 UTC
Permalink
Post by Michael Biebl
Post by 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
Post by Michael Biebl
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.
Post by Michael Biebl
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.
martin f krafft
2015-03-29 06:28:20 UTC
Permalink
Post by Christoph Anton Mitterer
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 <***@d.o> @martinkrafft
: :' : proud Debian developer
`. `'` http://people.debian.org/~madduck
`- Debian - when you have better things to do than fixing systems
Martin Steigerwald
2015-03-29 10:01:10 UTC
Permalink
Post by martin f krafft
Post by Christoph Anton Mitterer
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
Christoph Anton Mitterer
2015-03-29 20:34:12 UTC
Permalink
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.
Martin Steigerwald
2015-03-29 09:59:10 UTC
Permalink
Post by Christoph Anton Mitterer
Post by Michael Biebl
Post by 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
Marco d'Itri
2015-03-29 10:47:51 UTC
Permalink
Post by Christoph Anton Mitterer
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.
Post by Christoph Anton Mitterer
$ geoiplookup 8.8.8.8
GeoIP Country Edition: US, United States
traceroutes from multiple non-US locations may surprise you.
Post by Christoph Anton Mitterer
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.
Post by Christoph Anton Mitterer
Post by Michael Biebl
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.
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
Christoph Anton Mitterer
2015-03-29 20:03:24 UTC
Permalink
Post by Marco d'Itri
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.
Post by Marco d'Itri
Post by Christoph Anton Mitterer
$ 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
***@heisenberg:~$ geoiplookup 209.85.253.113
GeoIP Country Edition: US, United States
***@heisenberg:~$ geoiplookup 64.233.175.121
GeoIP Country Edition: US, United States
***@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.
Post by Marco d'Itri
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.
Post by Marco d'Itri
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.
Post by Marco d'Itri
- 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.
Post by Marco d'Itri
- 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.
张敬强
2015-03-29 11:05:54 UTC
Permalink
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.
martin f krafft
2015-04-07 18:45:59 UTC
Permalink
Marco,

is your position unchanged?

Thanks,
--
.''`. martin f. krafft <***@d.o> @martinkrafft
: :' : proud Debian developer
`. `'` http://people.debian.org/~madduck
`- Debian - when you have better things to do than fixing systems
Christoph Anton Mitterer
2015-04-07 19:11:49 UTC
Permalink
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.
Marco d'Itri
2015-04-07 20:22:20 UTC
Permalink
Post by martin f krafft
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
Christoph Anton Mitterer
2015-04-07 20:43:19 UTC
Permalink
Post by Marco d'Itri
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?
Post by Marco d'Itri
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.
Post by Marco d'Itri
, 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?
Post by Marco d'Itri
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.
Christoph Anton Mitterer
2015-04-07 21:26:46 UTC
Permalink
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
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.
Post by Christoph Anton Mitterer
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.
Post by Christoph Anton Mitterer
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.
Post by Christoph Anton Mitterer
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.
Post by Christoph Anton Mitterer
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.
Post by Christoph Anton Mitterer
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.
martin f krafft
2015-04-07 20:45:16 UTC
Permalink
Post by Marco d'Itri
Post by martin f krafft
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.
Post by Marco d'Itri
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 <***@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
Christoph Anton Mitterer
2015-04-07 20:56:17 UTC
Permalink
Post by martin f krafft
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.
Marco d'Itri
2015-04-07 20:57:59 UTC
Permalink
Post by martin f krafft
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.
Post by martin f krafft
Our MTAs don't have default mail relays.
At least because there is no such service available.
Post by martin f krafft
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.
Post by martin f krafft
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.
Post by martin f krafft
So no, no concrete threat model. But I hope I was able to argue that
Cool, everything is still OK then.
--
ciao,
Marco
Michael Biebl
2015-04-07 21:13:05 UTC
Permalink
Post by Marco d'Itri
Post by martin f krafft
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?
martin f krafft
2015-04-08 07:55:03 UTC
Permalink
Post by Marco d'Itri
Post by martin f krafft
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.
Post by Marco d'Itri
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.
Post by Marco d'Itri
Post by martin f krafft
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.
Post by Marco d'Itri
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 <***@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
Michael Biebl
2015-04-08 08:45:12 UTC
Permalink
Post by martin f krafft
Post by Marco d'Itri
Post by martin f krafft
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?
martin f krafft
2015-04-08 09:33:29 UTC
Permalink
Post by Michael Biebl
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 <***@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
Michael Biebl
2015-04-08 09:44:26 UTC
Permalink
Post by martin f krafft
Post by Michael Biebl
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.
Post by martin f krafft
¹) 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?
martin f krafft
2015-04-08 09:54:15 UTC
Permalink
Post by Michael Biebl
Post by martin f krafft
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.
Post by Michael Biebl
Post by martin f krafft
¹) 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 <***@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.
Christoph Anton Mitterer
2015-04-08 13:03:11 UTC
Permalink
Post by Michael Biebl
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.
Post by Michael Biebl
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.
Post by Michael Biebl
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.
Post by Michael Biebl
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.

Continue reading on narkive:
Loading...