On Tue, 15.07.14 11:05, Dan Williams (d...@redhat.com) wrote: > > On Tue, 2014-07-15 at 17:17 +0200, Lennart Poettering wrote: > > On Mon, 14.07.14 15:38, Dan Williams (d...@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 _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
