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

Marcel Holtmann marcel at holtmann.org
Thu Dec 12 07:28:10 PST 2013


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.

Just to be clear, I have nothing against the general idea, I am just saying that NSS itself with its current design is pretty limited. And keep working around it is not helping either.

Regards

Marcel



More information about the systemd-devel mailing list