[systemd-devel] [RFC] Initial libsystemd-asyncns commit

[Lennart Poettering]

On Thu, 12.12.13 16:28, Marcel Holtmann (marcel at holtmann.org) wrote:

> 
> Hi Lennart,
> 
> >>>>>> why do we have to spawn threads or do forks for DNS. This looks all
> >>>>>> pretty expensive. In ConnMan for example we just wrote our own async
> >>>>>> DNS using a mainloop. Works perfectly fine and is dirt cheap.
> >>>>> 
> >>>>> Well, we don't fork threads/processes for each call but reuse them.
> >>>>> 
> >>>>> What libasyncns does what your solution doesn't do is go via NSS. This
> >>>>> means /etc/hosts, nss-myhostname, nss-ldap, nss-mdns and so on just
> >>>>> work, while that all is lost when doing DNS natively.
> >>>>> 
> >>>>> I am pretty sure we should not bypass NSS for this. 
> >>>> 
> >>>> actually NSS for DNS is pretty nasty stuff. I am pretty sure we should bypass it and create a proper implementation. Is anybody actually using NIS or LDAP for domain name resolution?
> >>>> 
> >>> 
> >>> Yes, there are solutions that are using LDAP for hostname resolution
> >>> quite heavily - actually are based around LDAP without any
> >>> local /etc/hosts.
> >> 
> >> that is extremely heavy and must suck form a latency point of
> >> view. Then again, nothing that a DNS<->LDAP bridge couldn’t easily
> >> support. Since dragging LDAP dependencies into every program that has
> >> to load NSS modules is not a good idea either.
> > 
> > Note that "nscd" was created to deal with the performance of the LDAP
> > setups and also doesn't require loading everything into the same process.
> 
> and that is an excuse to keep using NSS modules? We took a rather
> shitty idea and hacked it up a little and it is now a little bit less
> shitty.

Well, I agree that NSS is a bit aged, given its synchronous
behaviour. But it's the only name resolving API that is somewhat
accepted these days. With systemd we try to keep the focus on the
general purpose, which means we cannot just decide that NSS is shit and
bypass all NSS modules. Or, maybe we can do that one day, but then we
have to have something that is at least is powerful, and supports
loadable modules and shit -- but we don't have that.

In the meantime, going via NSS is the only viable option I think. And
the API is generic enough to allow other backends too. It's a 1:1
translation of the classic getaddrinfo() interface to an async way of
things. Whether there's actually getaddrinfo() behind it doesn't really
matter, we can totally swap that out.

For example, if eventuallly we have some kind of local DNS resolver
daemon that can do split horizon and whatnot, and also supports an
interface for LDAP, mdns, ... then we can certainly talk to that
directly from the same lib, nobody needs to know that...

Lennart

-- 
Lennart Poettering, Red Hat