[systemd-devel] systemd-networkd fails to get DHCPv4 lease with disabled IPv6

[Lennart Poettering]

On Tue, 15.07.14 11:05, Dan Williams (dcbw at redhat.com) wrote:

> 
> On Tue, 2014-07-15 at 17:17 +0200, Lennart Poettering wrote:
> > On Mon, 14.07.14 15:38, Dan Williams (dcbw at redhat.com) wrote:
> > 
> > > But that brings up another question; I don't think systemd-networkd is
> > > currently capable of ensuring a machine is completely configured when RA
> > > is enabled, because it doesn't handle RDNSS and DNSSD options from the
> > > RA response.  The kernel can't handle those, because those require
> > > writing to /etc/resolv.conf (or a caching nameserver), which the kernel
> > > obviously doesn't do.  But neither does systemd-networkd.
> > 
> > systemd-resolved subscribes to networkd state and writes out those
> > files. It's simply a matter of making networkd pass the RDNSS/DNSSL
> > records to resolved, too.
> 
> Will resolved grow an interface that other services can use to push that
> information down to it, in addition to the existing approach of
> listening to networkd events in /run/systemd/netif and then parsing
> systemd network config/lease files?

Note that resolved is a moving target. 5 minutes ago it was simply a
mini-daemon that wrote its own resolv.conf based on networkd's DNS
data. Admins could then link /etc/resolv.conf to that file, and take
benfit of this.

3mins ago I pushed some initial code that turns resolved into much more:
it's supposed to become a local caching stub resolver for DNS,
mDNS/DNS-SD and LLMNR, with support for DNSSEC and IDN. 

The idea is that there'll be an NSS module for hooking up getaddrinfo()
and friends with this. I also intend to port sd-resolve (i.e. the
asynchronous resolver library we ship with systemd, that isn't public
yet) to it, so that it talks to it when used for RR resolving.

I also intend to add some support to systemd socket units to register
DNS-SD services with resolved. Also, I want to provide compatibility
with Avahi, so that all avahi clients simply work on top of
resolved. (yes, i am cannibalizing one of my own projects).

My current plan for resolved is to regularly stat() /etc/resolv.conf. If
it is a symlink to its own version in /run, then it will ignore
it. However, if it is a regular file or symlink anywhere else, it will
read it and use it as additional configuration source for DNS servers to
contact.

This is supposed to be good enough to provide compatibility with foreign
network management daemons (i.e. not networkd), since writing out
/etc/resolv.conf is the only somewhat established way of communicating
acquired DNS servers. 

Of course, if used in conjunction with networkd there are certain things
not available otherwise. For example, one of the things I hope to fix
properly with this are DNS in VPN setups: name look-ups which aren't
clearly bound to specific interfaces are posted on all interfaces and
all replies collected. The first positive server reply is returned to the
caller. If all server replies are negative then finally a negative reply
is returned to the caller too. This should allow names in a LAN to stay
resolvable even if one is connected to a VPN that traditionally would
override DNS settings... Now, this logic requires that we clearly know
which DNS server belongs to which interface. From simply reading
/etc/resolv.conf we won't get that information.

We currently have no plans regarding any other integration with other
network management stacks, beyond /etc/resolv.conf. Sorry.

Lennart

-- 
Lennart Poettering, Red Hat