Currently c-ares fulfills our needs just fine.
The bug referenced makes sense for a normal userspace app, but I don't think it is applicable to SSSD for a few reasons.

• We need to fetch SRV records and if I remember correctly the nsswitch interface has no API to do that.

• mDNS is an insecure name resolution protocol that works only for link-local resolution. I don't think SSSD is currently interested in using it. If a strong case is made to allow SSSD to use mDNS then we might reconsider. In that case we would probably favor adding explicit support though.

• We are thinking of making SSSD a nsswitch provider for the hosts target so we can properly cache hostnames just like we cache identities. In that case recursing into nsswitch wouldn't be a good idea :)

• Going forward we may want to start checking DNSSEC signatures, again the nsswitch interface cannot currently provide this information.

HTH

Simo's summary is very accurate. There are many reasons why we are using c-ares and should not switch.

In addition to his comments, the other problem with libasyncns is that it requires pthreads to operate, which would introduce immeasurable issues in our single-threaded daemons.

resolution: => wontfix
status: new => closed

Fields changed

rhbz: => [https://bugzilla.redhat.com/show_bug.cgi?id=554305 554305]

SSSD is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in SSSD's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/SSSD/sssd/issues/1738

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.