My guess is that rls-bb-notfixing means this is not getting fixed in
Bionic Beaver 18.04. Really hoping a fix can make it into the 20.04 LTS
release though.
I agree with Paul - systemd-resolve is not doing what it promises to do.
>From systemd.network(5):
Both "search" and "routing-only" domains are used for routing of DNS
queries:
look-ups for host names ending in those domains (hence also single label
names, if
any "search domains" are listed), are routed to the DNS servers configured
for
this interface. The domain routing logic is particularly useful on
multi-homed
hosts with DNS servers serving particular private DNS zones on each
interface.
The "routing-only" domain "~." (the tilde indicating definition of a
routing
domain, the dot referring to the DNS root domain which is the implied
suffix of
all valid DNS names) has special effect. It causes all DNS traffic which
does not
match another configured domain routing entry to be routed to DNS servers
specified for this interface. This setting is useful to prefer a certain
set of
DNS servers if a link on which they are connected is available.
This setting is read by systemd-resolved.service(8). "Search domains"
correspond
to the domain and search entries in resolv.conf(5). Domain name routing has
no
equivalent in the traditional glibc API, which has no concept of domain name
servers limited to a specific link.
One partial workaround is to remove `[!UNAVAIL=return]` after `resolve`
in /etc/nsswitch.conf:
hosts: files mdns4_minimal [NOTFOUND=return] resolve dns myhostname
That way a traditional DNS resolution is done after systemd-resolve
fails. This works for everything I've tested so far _except_ Google
Chrome.
--
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/1726124
Title:
DNS domain search paths not updated when VPN started
Status in network-manager package in Ubuntu:
Confirmed
Status in network-manager-openvpn package in Ubuntu:
Confirmed
Status in systemd package in Ubuntu:
Confirmed
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@.service →
/lib/systemd/system/user@.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
--
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
