Issues related to the yakkety switch to systemd-resolved

[Martin Pitt]

Hello Joe,

Joe Barnett [2016-10-18  7:27 -0700]:
> Since upgrading to yakkety, I've noticed the following issues seemingly
> related to (a partial?) switch to systemd-resolved for DNS:

Yes, it's partial still. See the blueprint [1] for detailled status.

> 1)  The first issue I noticed was that when connected to an openvpn VPN,
> firefox stopped being able to resolve DNS entries from the VPN's DNS
> server, while command line tools (host/ping) worked fine.  Traced this down
> to two things, both seemingly related to my former use of resolvconf not
> fully migrating over to use systemd-resolved:

Note that we did not (and did not plan to) migrate away from
resolvconf -- too many packages hook into it which would need to get
changed first, so we continue to let /etc/resolv.conf be managed by
resolvconf for the time being.

>     a) Had to change my .ovpn file to point to
> /etc/openvpn/update-systemd-resolved
> instead of /etc/openvpn/update-resolv-conf
>     b) Had to change my /etc/resolv.conf to point to
> /lib/systemd/resolv.conf instead of /run/resolvconf/resolv.conf

So while trying that is appreciated, it *will* break resolv.conf
mangling integration with a lot of packages [2]. None of these should
affect a reasonably standard desktop, but you should be aware of it.

> 2) After a suspend/resume cycle, DNS queries stopped working unless I
> restarted network-manager: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1629620
>     a) After doing the fixes for problem #1, this appears to be working
> better now

That's unrelated to resolved, as NM is still configuring dnsmasq (and
hence /etc/resolv.conf should have 127.0.1.1 only). I've heard reports
that a recent change in NM (https://launchpad.net/bugs/1592721) broke
split-horizon DNS for some people, and from a quick IRC debugging it
seemed that dnsmasq was in a weird state after (re)starting NM.
Killing the dnsmasq instances and re-connecting to the network (in
nm-applet) helped these folks -- does it work for you too?

> 3) Steam was unable to see the network: https://bugs.launchpad.net/
> ubuntu/+source/steam/+bug/1631980
>     a) After manually installing libnss-resolve:i386, this is now resolved,
> but should this package have been installed automatically when
> libnss-resolve:amd64 was installed?

No, that can't work. Ideally, libnss-resolve:i386 would be installed
automatically as soon as you install any :i386 package. However,
unlesss we make libc6:i386 Recommends: libnss-resolve, we don't have
any mechanics for that.

For this we actually keep the "dns" fallback in /etc/nsswitch.conf, so
that foreign-architecture programs still use the plain old
/etc/resolv.conf for resolution if they don't have the corresponding
"resolve" NSS module  installed.

> Anyways, assuming there's eventually a fix found for #4, my real question
> is not so much that there were bugs, but rather are there still changes
> that should be made to make the solution for these issues more automatic
> (ie, automatically apply 1.b and 3.a)?  Or at least to notify the user more
> loudly that their configuration is not fully supported?

In principle everything ought to work as before on a desktop with NM.
So we don't need notifications IMHO, we "just" need to debug and fix
the dnsmasq regression (see above) for 16.10.

For 17.04 I'd actually like to finish the transition on the desktop as
well and move NM away from dnsmasq, so that we use the same solution
on servers and desktops. (Again see [1]).

Martin

[1] https://blueprints.launchpad.net/ubuntu/+spec/foundations-y-local-resolver
[2] http://people.canonical.com/~pitti/tmp/resolvconf-hooks.txt

-- 
Martin Pitt                        | http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)