Hello Malcolm, or anyone else affected, Accepted systemd into zesty-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/systemd/232-21ubuntu7 in a few hours, and then in the -proposed repository.
Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed.Your feedback will aid us getting this update out to other Ubuntu users. If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-zesty to verification-done-zesty. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-zesty. In either case, details of your testing will help us make a better decision. Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance! ** Tags removed: verification-done verification-done-zesty ** Tags added: verification-needed verification-needed-zesty -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, 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 Committed 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 -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
