[systemd-devel] [RFC 0/6] A network proxy management daemon, systemd-proxy-discoveryd

[Dan Williams]

On Sun, 2015-04-12 at 20:31 +0200, Lennart Poettering wrote:
> On Fri, 10.04.15 14:05, Dan Williams (dcbw at redhat.com) wrote:
> 
> > > > > So idea would basically be that we provide in all three daemons calls
> > > > > like:
> > > > > 
> > > > >         SetAdditionalNTP(ias)
> > > > >         SetAdditionalDNS(ia(uay)) 
> > > > 
> > > > I would strongly suggest using strings in the API for IP addresses, not
> > > > byte arrays.  
> > > 
> > > Why so?
> > 
> > It's much easier to use for languages other than C, like Python or JS or
> > Ruby or dbus-send or even C in many cases.  We originally used binary
> > addresses in the D-Bus interface for NetworkManager, and eventually
> > found that was the wrong choice for these reasons.  It's also easier to
> > pull in and out of D-Bus, with dbus-glib or GIO.  I'm not sure about
> > sd_bus though.
> 
> I am very much convinced that passing normalized data through dbus is
> the right thing. And that implies byte arrays for binary data such as
> IP addresses... We have structured data in dbus, that's pretty much
> the biggest benefit of dbus over raw sockets. We should use it and not
> chicken out, because our bindings suck and encode everything in
> formatted strings after all... If it's not easy to decode structured
> data with your bus binding, then the answer is to fix the bus binding,
> not to just revert to unstructured data.
> 
> > > > Also, remember that we want to push domains too, for split
> > > > DNS in the VPN or other cases.  So it really should be something like:
> > > > 
> > > > SetAdditionalDNS(ia(sas))  (index, array[domain, array[server]])
> > > > 
> > > > what were the (uay) arguments you proposed?
> > > 
> > > resolved supprots split DNS, but it will not allow multiple DNS
> > > servers with different domains on the same interface. Instead, you
> > > bind a set of DNS servers and a set of domains to an interface, and
> > > that's it, there's no further connection between servers and domains.
> > 
> > If I understand correctly, this means you cannot direct *.foobar.com to
> > one set of DNS servers,and *.baz.com to another set, assuming those are
> > bound to the same interface?  Why not allow that?
> 
> Well, resolved is not supposed to support every crazy set up people
> can think of. I mean, if they want that they can certainly run their
> own local DNS server. resolved is about figuring out the common
> usecases and covering them nicely and automatically, and little else.
> 
> > > I fail to see the strong usecase for allowing per-server domains. I
> > > mean in the VPn case you have one explicit interface for the VPN
> > > connection, so this should be covered with the current design.
> > 
> > IPSec doesn't give you an kernel netdev at all, it's just routing on an
> > existing interface.  So for that interface, you'd have both the VPN
> > servers and upstream servers, all bound to the same interface, and no
> > ability to direct VPN domains to the VPN servers since they are all on
> > the same interface?
> 
> IPSec used in that mode does not convey DNS server info, does it? In
> that case it's supposed to be transparent, but with such domain server
> config it wouldn't be transparent after all...

It certainly can convey DNS information.  Try the Red Hat VPN servers
with libreswan for an example.  Your eth0 will now have the original,
DHCP/static/etc provided LAN DNS servers, and secondary VPN-provided DNS
servers that can be tied to one or more domains that the VPN also
provided.

Dan