On Tue, May 31, 2016 at 11:34:41AM +0200, Martin Pitt wrote:
> yesterday I landed [1] in Yakkety which changes how DNS resolution
> works -- i. e. how names like "www.ubuntu.com" get translated to an IP
> address like 1.2.3.4.
> Now DNS resolution goes via a new "libnss-resolve" NSS module which
> talks to resolved [2]. /etc/resolv.conf has the "real" nameservers,
> broken name servers are handled efficiently, and we have local DNS
> caching. NetworkManager now stops launching a dnsmasq instance.
Please forgive this email for rambling; it's length and lack of focus
may reflect questions and uncertaintyy the larger community may have,
however, so I'm sending it anyway. :)
== /etc/resolv.conf ==
/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 ).
- 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?)
- 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?
- 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)?
== /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.
- When would 'hosts: .. resolve .. dns' be a better configuration than
'hosts: .. resolve ..' ?
== 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?
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.
I've spent enough time fighting dnsmasq and resolvconf that I'd quite
like to try replacing dnsmasq and resolvconf entirely. An NSS-based
interface may be able to do better.
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?
== LLDNS ==
Will we enable LLDNS? Do we want to? Responding too?
Thanks
