This bug was fixed in the package network-manager - 1.2.2-0ubuntu4

---------------
network-manager (1.2.2-0ubuntu4) yakkety; urgency=medium

  [ Mathieu Trudel-Lapierre ]
  * debian/patches/libnm-Check-self-still-NMManager-or-not.patch: updated and
    refreshed to make gbp pq happy.
  * debian/patches/Read-config-from-run.patch: also read configuration from
    /run, which is to override whatever might be shipped in /usr/lib; and be
    overriden by /etc or command-line arguments. (LP: #1591898)
  * debian/10-globally-managed-devices.conf: ship a default config to
    explicitly unmanage anything that is not wifi or wwan: we definitely want
    NM to manage wifi and mobile data; and probably don't want it to touch
    wired in many cases.
  * debian/network-manager.postinst: on upgrade from previous versions of NM,
    make sure we migrate from no global "unmanaged" policy to something
    equivalent where we may have a global policy, but explicitly override it
    to be disabled; so that on upgrade users do not suddenly see some of their
    network devices no longer being handled by NM.
  * debian/patches/dns-manager-don-t-merge-split-DNS-search-domains.patch: do
    not add split DNS search domains to resolv.conf; doing so would risk
    leaking names to non-VPN DNS nameservers when attempting to resolve non-
    FQDN names. (LP: #1592721)

  [ Martin Pitt ]
  * debian/NetworkManager.conf: Put back dns=dnsmasq for now. Some important
    applications such as Chrome don't use NSS but reimplement DNS resolution,
    for those we need a local DNS server. Until resolved gets one, we continue
    to use the NM specific dnsmasq on the desktop. Correspondingly, revert
    libnss-resolve recommends back to dnsmasq-base depends.

 -- Mathieu Trudel-Lapierre <[email protected]>  Thu, 16 Jun 2016
09:54:02 +0300

** Changed in: network-manager (Ubuntu)
       Status: In Progress => Fix Released

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/1592721

Title:
  Don't write search domains to resolv.conf in the case of split DNS

Status in network-manager package in Ubuntu:
  Fix Released

Bug description:
  Currently, NM will write all search domains to both any DNS-handling
  plugins running, and also to resolv.conf / resolvconf; in all cases.

  The issue is that doing so means that in the split-DNS case on VPNs,
  you might get a negative response from all nameservers, then a new
  request by glibc with the search tacked on, to nameservers again,
  which might cause DNS requests for "private" resources (say, on the
  VPN) to be sent to external, untrusted resolvers, or for DNS queries
  not meant for VPN nameservers to be sent through the VPN anyway.

  This is fixable in the case where we have a caching plugin running
  (such as dnsmasq). dnsmasq will already know about the search domains
  and use that to limit queries to the right nameservers when a VPN is
  running. Writing search domains to resolv.conf is unnecessary in this
  case.

  We should still write search domains if no caching gets done, as we
  then need to expect glibc to send requests as it otherwise would.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1592721/+subscriptions

-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to     : [email protected]
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp

Reply via email to