[Bug 1726124] Re: DNS domain search paths not updated when VPN started

[Paul Smith]

I'm not sure I understand what you mean.  In a typical configuration you
never send "foo" to the nameservice, there's always a search domain and
those lookups are always tried first (because the default value for the
ndots is 1).  This is handled by the libc resolver linked into every
program, it's not handled by a central service.

I don't have any idea how systemd-resolve works.  But, my understanding
of how it used to work with dnsmasq using split tunneling was that the
nameservice mapped domains to DNS servers, and the resolver would only
forward requests to the DNS server that matched the domain for the host
being requested.

If you have a VPN interface that adds "mycorp.com" to the search domain
that appears in /etc/resolv.conf search, so it contains "mycorp.com
localdomain" for example.  Then when someone tries to resolve "myhost",
the libc resolver sees that there are no dots here and so it starts
appending search paths to the hostname, in order, and sending them to
the DNS service to look up.  So first it will send "myhost.mycorp.com"
to the resolver.  The resolver sees that the hostname ends in
"mycorp.com" and it knows that the VPN DNS servers "own" that domain, so
it forwards that request to those servers for lookup.

If that doesn't match, then the libc resolver will try to look up
"myhost.localdomain".  That does NOT match the VPN domain, so it will
not try to forward that to the DNS servers for the VPN connection and
instead use a different resolver.

I don't think there's any information leakage here.

-- 
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/1726124

Title:
  DNS domain search paths not updated when VPN started

Status in network-manager package in Ubuntu:
  New
Status in network-manager-openvpn package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  New

Bug description:
  I connect to work with openvpn through network-manager-openvpn.  I'm
  selecting automatic (DHCP) to get an IP address, and "Use this
  connection only for resources on its network" to support split
  tunneling.

  In the last few versions of Ubuntu I used, this all worked fine.  In
  Ubuntu 17.10 (fresh install, not upgrade) I can access hosts on both
  my VPN network and the internet, BUT I have to use FQDN for my VPN
  network hosts: the updates to the DNS search path provided by my VPN
  DHCP server are never being applied.

  Investigating the system I see that /etc/resolv.conf is pointing to
  /run/systemd/resolve/stub-resolv.conf and that resolv.conf does not
  have any of the VPN's search path settings in it:

    # This file is managed by man:systemd-resolved(8). Do not edit.
    #
    # 127.0.0.53 is the systemd-resolved stub resolver.
    # run "systemd-resolve --status" to see details about the actual nameservers.
    nameserver 127.0.0.53

    search home

  In previous versions of Ubuntu, where NetworkManager controlled the
  resolver not systemd, /etc/resolv.conf pointed to
  /run/NetworkManager/resolv.conf and there was a local dnsmasq instance
  that managed all the complexity.  In Ubuntu 17.10 when I look in
  /run/NetworkManager/resolv.conf file, I see that the search paths ARE
  properly updated there:

    $ cat /run/NetworkManager/resolv.conf 
    # Generated by NetworkManager
    search internal.mycorp.com other.mycorp.com home
    nameserver 127.0.1.1

  However this file isn't being used, and also there's no dnsmasq
  running on the system so if I switch my /etc/resolv.conf to point to
  this file instead, then all lookups fail.

  Strangely, if I look at the systemd-resolv status I see that in theory
  systemd-resolve does seem to know about the proper search paths:

    $ systemd-resolve --status
       ...
    Link 3 (tun0)
          Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6
           LLMNR setting: yes
    MulticastDNS setting: no
          DNSSEC setting: no
        DNSSEC supported: no
             DNS Servers: 10.3.0.10
                          10.8.42.2
              DNS Domain: ~internal.mycorp.com
                          ~other.mycorp.com

  but for whatever reason the search domains are not getting put into
  the resolv.conf file:

    $ host mydesk
    ;; connection timed out; no servers could be reached

    $ host mydesk.internal.mycorp.com
    mydesk.internal.mycorp.com has address 10.8.37.74

  (BTW, the timeout in the failed attempt above takes 10s: it is SUPER
  frustrating when all your host lookups are taking that long just to
  fail).

  ProblemType: Bug
  DistroRelease: Ubuntu 17.10
  Package: systemd 234-2ubuntu12
  ProcVersionSignature: Ubuntu 4.13.0-16.19-generic 4.13.4
  Uname: Linux 4.13.0-16-generic x86_64
  ApportVersion: 2.20.7-0ubuntu3
  Architecture: amd64
  CurrentDesktop: GNOME
  Date: Sun Oct 22 15:08:57 2017
  InstallationDate: Installed on 2017-10-21 (1 days ago)
  InstallationMedia: Ubuntu 17.10 "Artful Aardvark" - Release amd64 (20171018)
  MachineType: System manufacturer System Product Name
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=<set>
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.13.0-16-generic root=UUID=4384306c-5fed-4b48-97a6-a6d594c4f72b ro quiet splash vt.handoff=7
  SourcePackage: systemd
  SystemdDelta:
   [EXTENDED]   /lib/systemd/system/rc-local.service → /lib/systemd/system/rc-local.service.d/debian.conf
   [EXTENDED]   /lib/systemd/system/user at .service → /lib/systemd/system/user at .service.d/timeout.conf
   
   2 overridden configuration files found.
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 12/02/2014
  dmi.bios.vendor: American Megatrends Inc.
  dmi.bios.version: 2101
  dmi.board.asset.tag: To Be Filled By O.E.M.
  dmi.board.name: M5A78L-M/USB3
  dmi.board.vendor: ASUSTeK Computer INC.
  dmi.board.version: Rev X.0x
  dmi.chassis.asset.tag: Asset-1234567890
  dmi.chassis.type: 3
  dmi.chassis.vendor: Chassis Manufacture
  dmi.chassis.version: Chassis Version
  dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr2101:bd12/02/2014:svnSystemmanufacturer:pnSystemProductName:pvrSystemVersion:rvnASUSTeKComputerINC.:rnM5A78L-M/USB3:rvrRevX.0x:cvnChassisManufacture:ct3:cvrChassisVersion:
  dmi.product.family: To Be Filled By O.E.M.
  dmi.product.name: System Product Name
  dmi.product.version: System Version
  dmi.sys.vendor: System manufacturer

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