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

Andrey Borzenkov arvidjaar at gmail.com
Thu Dec 12 05:54:01 PST 2013


В Thu, 12 Dec 2013 14:09:42 +0100
Marcel Holtmann <marcel at holtmann.org> пишет:

> 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.

> The problem with NSS is that it still does not fix the fundamental problem. It is sequential and blocking. You can spawn as many threads as you want and it will stay sequential.
> 
> I fully agree with you that we need to consider /etc/hosts, the local hostname and also mDNS, but I get the feeling it would be more beneficial to just build that in. ConnMan ships a DNS proxy cache to actually be able to be smart and parallel. We did not bother with the details like /etc/hosts so far since our use cases always had an empty /etc/hosts with just localhost only anyway. However that is easy to fix.
> 
> Spawning threads or forking is expensive (even if you reuse it) comparing to what you actually do here. You just want to resolve a host. It is especially expensive since you can not control on what is actually used. And there are clearly use cases where you have to ask a specific nameserver or set of nameservers.
> 
> Regards
> 
> Marcel
> 
> _______________________________________________
> systemd-devel mailing list
> systemd-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel



More information about the systemd-devel mailing list