This bug was fixed in the package systemd - 232-21ubuntu7
---------------
systemd (232-21ubuntu7) zesty; urgency=medium
* networkd: accept `:' in ifnames in systemd/networkd. (LP: #1714933)
* networkd: add support for ActiveSlave and PrimarySlave netdev options.
(LP: #1709135)
* Cherrypick upstream fix for a race between .mount and .automount units,
which currently may result in automounts hanging. (LP: #1709649)
* systemd.postinst: Fix-up version number check in the previous sru.
The version check in the postinst was too tight, thus the SRU fix failed
validation. (LP: #1710410)
systemd (232-21ubuntu6) zesty; urgency=medium
* link: Fix offload features initialization.
This fixes a regression introduced in v232 which caused TCP
segmentation offloads being disabled by default, resulting in
significant performance issues under certain conditions. (Closes: #864073)
(LP: #1703393)
* loginctl: Fix loginctl ignoring user given session IDs at command-line
(LP: #1682154)
* Disable fallback DNS servers.
This causes resolved to call-home to google, attempt to access network when
none is available, and spams logs. (LP: #1449001)
* initramfs-tools: trigger udevadm add actions with subsystems first.
This updates the initramfs-tools init-top udev script to trigger udevadm
actions with type specified. This mimicks the
systemd-udev-trigger.service. Without type specified only devices are
triggered, but triggering subsystems may also be required and should happen
before triggering the devices. This is the case for example on s390x with zdev
generated udev rules. (LP: #1713536)
* Enable systemd-resolved by default. (LP: #1710410)
* core: fix systemd failing to serialize tasks correctly on daemon-reload.
(LP: #1702823)
-- Dimitri John Ledkov <xnox at ubuntu.com> Wed, 04 Oct 2017 14:22:02
+0100
** Changed in: systemd (Ubuntu Zesty)
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1449001
Title:
systemd-resolved: please do not use Google public DNS by default
Status in systemd:
New
Status in systemd package in Ubuntu:
Fix Released
Status in systemd source package in Zesty:
Fix Released
Status in systemd source package in Artful:
Fix Released
Status in systemd package in Debian:
Fix Released
Bug description:
[Impact]
systemd-resolved will fall back to Google public DNS (8.8.8.8, etc.) in the absence of other configured DNS servers.
systemd-resolved is not enabled by default in Ubuntu 15.04, but it is
installed by default and will behave in this way if enabled by the
user.
$ cat /etc/systemd/resolved.conf
(...)
# Entries in this file show the compile time defaults.
(...)
#FallbackDNS=8.8.8.8 8.8.4.4 2001:4860:4860::8888 2001:4860:4860::8844
This raises privacy concerns since in the event of accidental
misconfiguration DNS queries will be sent unencrypted across the
internet, and potentially also security concerns given systemd-
resolved does not perform DNSSEC validation and is not particularly
well hardened against malicious responses e.g. from a MITM
(http://www.openwall.com/lists/oss-security/2014/11/12/5).
I believe that it would be better to fail safe if no DNS server is
configured -- i.e. have DNS lookups fail; it's better that the user is
aware of their misconfiguration, rather than silently sending their
queries to Google. The user can intentionally opt to use Google
public DNS if they wish.
[Testcase]
Steps to reproduce:
1. Remove existing DNS configuration (from /etc/network/interfaces, /etc/resolv.conf, /etc/resolvconf/resolv.conf.d/*)
2. Reboot, or otherwise clear relevant state
3. sudo service systemd-resolved start
4. Note that Google's servers are listed in /run/systemd/resolve/resolv.conf
5. If systemd-resolved is enabled in /etc/nsswitch.conf (it isn't by default), observe that DNS lookups probably still work, and queries are being sent to one of Google's servers
Possible workaround/bugfix: ship a resolved.conf which clears the
FallbackDNS parameter.
[Solution]
In ubuntu, we disable fallback DNS at build time, via build system configuration flags.
This issue has been discussed in the Debian BTS
(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=761658). My
interpretation of the Debian package maintainer's position is that a
user concerned with the privacy implications shouldn't let systemd get
into a state where it uses the fallback DNS servers (quoting Marco
d'Itri: "Short summary: have a resolv.conf file or use DHCP"). I
would argue that it's safest not to have fallback DNS servers
configured at all by default.
[Regression Potential]
Missconfigured networks, that do not have a DNS server would previously magically work due to having Google DNS preconfigured regardless. With this change, such network configurations will fail to work, and one will have to properly fix network config to point at the right/existing name server.
To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/1449001/+subscriptions