Fields changed

description: This probably isn't a huge problem, but I noticed that sssd tried to do a DNS lookup when I had specified an LDAP server by IP address. It seems to me that if it's just an IP address that it shouldn't try to do a DNS lookup. Here's the relevant debug output:

[sssd[be[LDAP]]] [fo_resolve_service_send] (4): Trying to resolve service 'LDAP'
[sssd[be[LDAP]]] [get_server_status] (7): Status of server '10.0.0.10' is 'name not resolved'
[sssd[be[LDAP]]] [get_port_status] (7): Port status of port 389 for server '10.0.0.10' is 'neutral'
[sssd[be[LDAP]]] [get_server_status] (7): Status of server '10.0.0.10' is 'name not resolved'
[sssd[be[LDAP]]] [resolv_gethostbyname_send] (4): Trying to resolve A record of '10.0.0.10'
[sssd[be[LDAP]]] [schedule_timeout_watcher] (9): Scheduling DNS timeout watcher
[sssd[be[LDAP]]] [set_server_common_status] (4): Marking server '10.0.0.10' as 'resolving name'
[sssd[be[LDAP]]] [unschedule_timeout_watcher] (9): Unscheduling DNS timeout watcher
[sssd[be[LDAP]]] [set_server_common_status] (4): Marking server '10.0.0.10' as 'name resolved'
[sssd[be[LDAP]]] [be_resolve_server_done] (4): Found address for server 10.0.0.10: [10.0.0.10] => This probably isn't a huge problem, but I noticed that sssd tried to do a DNS lookup when I had specified an LDAP server by IP address. It seems to me that if it's just an IP address that it shouldn't try to do a DNS lookup. Here's the relevant debug output:

{{{
[sssd[be[LDAP]]] [fo_resolve_service_send] (4): Trying to resolve service 'LDAP'
[sssd[be[LDAP]]] [get_server_status] (7): Status of server '10.0.0.10' is 'name not resolved'
[sssd[be[LDAP]]] [get_port_status] (7): Port status of port 389 for server '10.0.0.10' is 'neutral'
[sssd[be[LDAP]]] [get_server_status] (7): Status of server '10.0.0.10' is 'name not resolved'
[sssd[be[LDAP]]] [resolv_gethostbyname_send] (4): Trying to resolve A record of '10.0.0.10'
[sssd[be[LDAP]]] [schedule_timeout_watcher] (9): Scheduling DNS timeout watcher
[sssd[be[LDAP]]] [set_server_common_status] (4): Marking server '10.0.0.10' as 'resolving name'
[sssd[be[LDAP]]] [unschedule_timeout_watcher] (9): Unscheduling DNS timeout watcher
[sssd[be[LDAP]]] [set_server_common_status] (4): Marking server '10.0.0.10' as 'name resolved'
[sssd[be[LDAP]]] [be_resolve_server_done] (4): Found address for server 10.0.0.10: [10.0.0.10]
}}}
milestone: NEEDS_TRIAGE => SSSD 1.2

The DNS resolver should identify an IPv4 or IPv6 address (in various notations) and skip the resolver step.

owner: somebody => jhrozek

This can be done, but I'm not sure if it's necessary - ares checks if the hostname looks like an IP address (inet_addr(), inet_pton() and friends) and returns immediatelly.

FTR, this is done in fake_hostent() function, in ares_gethostbyname.c:238

After some more discussion off-list we decided that this is not a bug, especially given that c-ares would return before actually sending any request over the network, so the delay in processing is minimal.

resolution: => invalid
status: new => closed

That seems fine. I didn't know that ares has this optimization. Thanks for looking into it.

Fields changed

rhbz: => 0

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/1460

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.