ANN: DNS resolver changes in yakkety

[Martin Pitt]

Hello Seth,

Seth Arnold [2016-06-03 21:30 -0700]:
> /etc/resolv.conf appears to be both a resolved configuration file ("global
> resolvers") as well as something it will publish for other programs to
> consume (the symlink to /run/systemd/resolve/resolv.conf ).

To clarify, it's a configuration file of glibc's NSS system, it's not
specific to resolved or resolvconf. And it's still managed by
resolvconf, like for the last umpteen Ubuntu releases.

> - Which programs would consume data from this file? (My guess is 'native'
>   lookup routines in languages like perl, python, ruby, erlang, java. Is
>   this close? Who else would read from this file? Should we let them?)

Mostly libc's gethostbyname() family, via libnss-dns. But as it's
an ancient standard config file, other programs surely read it as
well, for example "dig" or "host" (which don't use glibc's API).

> - Would we want to stop using resolvconf? It feels like resolvconf's uses
>   would be drastically less important with good systemd-networkd
>   configuration instead. Would any cases remain where we want to keep
>   resolvconf?

I looked into that, as resolved can manage resolv.conf as well. But
it's deeply entrenched into Debian/Ubuntu packages [1], so we'd need
to adjust quite a number of packages to talk to resolved instead.
Doable, but it's unrelated to the main goal of the spec, so I didn't
propose this for now.

That said, networkd will still send DNS information that cannot be
represented in resolv.conf (such as domain-specific DNS servers) to
resolved -- that is, *if* you use such features in networkd, you
*have* to use libnss-resolve for it to actually work.

[1] http://people.canonical.com/~pitti/tmp/resolvconf-hooks.txt

> - Will we go with the symlink route (i.e., resolved is the publisher) or
>   will we go with the regular file route (i.e., resolved is the consumer)?

No change planned, see above.

> == /etc/nsswitch.conf ==
> 
> > [2] This is configured in /etc/nsswitch.conf ("hosts: files ... resolve dns")
> 
> Do we even want to keep 'dns' on this line? If resolved fails to resolve
> a request then falling back to DNS feels like it will simply push the
> inevitable failure off by another six to eighteen seconds.

libnss-resolve automatically falls back to "dns" (i. e. libnss-dns) if
resolved isn't running or cannot be contacted. So indeed we don't need
it for most cases.

The issue is with multi-arch installations: Suppose you only have
libnss-resolve:amd64 installed, and then install foo:i386. The latter
wouldn't have libnss-resolve available. That's the only reason why we
still need the "dns" line there. Alternatively we would need to figure
out a way to install libnss-resolve:<arch> whenever we install the
first package on <arch>.

> == replace dnsmasq's combined dhcpd and "local" dns ==
> 
> - Will dhcp leases handed out by systemd's dhcp server be automatically
>   entered into the resolved database for lookups?

Clarification: resolved is not a DHCP server, it's just a resolver.
I'm trying to interpret what you mean by this: DNS servers picked up
by networkd (via DHCP or config files) get sent to resolved, yes.

networkd also has a small builtin DHCP (v4 only) server, which can be
enabled with "DHCPServer=yes". This does not have many features
though, it's main intention is to provide simple DHCP to containers on
embedded systems which don't want to setup anything more complicated.
But we don't use this, as in Ubuntu "container" == "LX[CD]", which
sets up dnsmasq.

> dnsmasq is used by many tools for these dual purposes and often times
> chained together with resolveconf but the fact that it is _chained_
> together means that e.g. containers can't look up VM names, or VMs
> can't look up container names, when both VMs and containers are hosted
> on one system.

systemd's approach for that is that container or VM managers such as
nspawn or libvirt register themselves in machined [2], and then you
can use libnss-mymachines to resolve their names. But again, our
current LXC/D don't use this. However, this was discussed with
Stéphane in a different part of this thread, I'm sure we can find a
solution here.

[2] https://www.freedesktop.org/wiki/Software/systemd/writing-vm-managers/

> Will we adapt lxd and libvirt and so on to use systemd-network so that
> resolved and the systemd dhcp server stand a chance of replacing the other
> tooling?

I don't know about libvirt. Since RH is heavily involved in this, I
figure it might  get direct machined/resolved integration at some
point for the above. I doubt it for lxc/lxd, though.

> == LLDNS ==
> 
> Will we enable LLDNS? Do we want to? Responding too?

Not sure what LLDNS is, do you mean LLMNR? Resolved does that indeed,
but we still have Avahi's libnss-mdns4 installed by default. I haven't
checked if that can go now. I added a work item to
https://blueprints.launchpad.net/ubuntu/+spec/foundations-y-local-resolver
to check this.

Thanks,

Martin

-- 
Martin Pitt                        | http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20160607/ad1a3540/attachment.pgp>