Tuesday, 31 May 2016

Re: ANN: DNS resolver changes in yakkety

Hello Stéphane,

Stéphane Graber [2016-05-31 11:23 -0400]:
> So in the past there were two main problems with using resolved, I'd
> like to confirm both of them have now been taken care of:
> 1) Does resolved now support split DNS support?
> That is, can Network Manager instruct it that only *.example.com
> should be sent to the DNS servers provided by a given VPN?

resolved has a D-Bus API SetLinkDomains(), similar in spirit to
dnsmasq. However, NM does not yet know about this, and only indirectly
talks to resolved via writing /etc/resolv.conf (again indirectly via
resolvconf). So the functionality on the resolved is there, but we
don't use it yet. This is being tracked in the blueprint.

> 2) Does resolved now maintain a per-uid cache or has caching been
> disabled entirely?

No, it uses a global cache.

> In the past, resolved would use a single shared cache for the whole
> system, which would allow for local cache poisoning by unprivileged
> users on the system. That's the reason why the dnsmasq instance we spawn
> with Network Manager doesn't have caching enabled and that becomes even
> more critical when we're talking about doing the same change on servers.

Indeed Tony mentioned this in today's meeting with Mathieu and me --
this renders most of the efficiency gain of having a local DNS
resolver moot. Do you have a link to describing the problem? This was
requested in LP: #903854, but neither that bug nor the referenced
blueprint explain that.

How would an unprivileged local user change the cache in resolved? The
only way how to get a result into resolvconf's cache is through a
response from the forwarding DNS server. If a user can do that, what
stops her from doing the same for non-cached lookups?

The caches certainly need to be dropped whenever the set of
nameservers *changes*, but this already happens. (But this is required
for functioning correctly, not necessarily a security guard).

If you have some pointers to the attack, I'm happy to forward this to
an upstream issue and discuss it there (or file an issue yourself,
tha'd be appreciated). If this is an issue, it should be fixed
upstream, not downstream by disabling caching completely.

> Additionally, what's the easiest way to undo this change on a server?

Uninstall libnss-resolve, or systemctl disable systemd-resolved, I'd

> I have a few deployments where I run upwards of 4000 containers on a
> single system. Such systems have a main DNS resolver on the host and all
> containers talking to it. I'm not too fond of adding an extra 4000
> processes to such systems.

I don't actually intend this to be in containers, particularly as
LXC/LXD already sets up its own dnsmasq on the host. That's why I only
seeded it to ubuntu-standard, not to minimal. The
images.linuxcontainers.org images (rightfully) don't have
ubuntu-standard, so they won't get libnss-resolve and an enabled



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