From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.0.5) Gecko/20060719 Firefox/1.5.0.5

Description of problem:
i think there is a small inconsistency in the nss_ldap
implementation leading to larger problems on application level
and in combination with other utilities:

nss_ldap-226-13 is built without IPv6 capabilities. I think this
is intended. When i try to a make with INET6 defined, i get errors
because the function map_v4v6_address is not available. The
function _nss_ldap_gethostbyname2_r behaves partially, as if it
was able to return IPv6 address entries: It does not return an
error, when an IPv6 entry is requested in the 2nd argument, it
silently ignores this argument and returns an IPv4 entry. This
is unlike nss_files, nss_dns, nss_nis and probably more modules.
Furthermore it contrasts to the man-page, that reads:

       Glibc2  also  has  a gethostbyname2() that works like gethostbyname(),
       but permits to specify the address family to which  the  address  must
       belong.

So passing AF_INET6 to the IPv6 unable function should always fail,
otherwise the calling environment could misinterpret the result
in the address structure as IPv6 address.
At least two programs come with the System that get confused by this,
these are nscd and getent, what leads to other problems.

nscd first calls gethostbyname2 requesting AF_INET6. gethostbyname2
returns with good status, so nscd thinks, the IPv6 lookup was
successful and passes a strange IPv6 hosts entry to the requestor.
For caching it stores the entire address structure, who contains AF_INET
as protocol specifier. Thus the next time queried, the nscd knows,
that it's a IPv4 address and the result is ok, but when the cache
gets invalid or being queried the first time, nscd delivers garbage.

getent does similar things and misbehaves in a different way: The
problem leads to an incorrectly evaluated hosts entry in nsswitch.conf .
Assume you have hosts: files ldap dns  in the nsswitch and you want
to override a hosts entry in ldap with an entry with the same name
in /etc/hosts . getent makes an IPv6 lookup through gethostbyname2 .
Looking up "files" fails (no Ipv6 address !), looking up LDAP
succeeds !!!!?! and returns the IPv4 entry found there.
Basically this problem is not that severe, nonetheless the result
is not the expected one.

The fix for the problem is very small and simple: e.g. adding the
following 4 lines to the ldap-hosts.c file, start of function
_nss_ldap_gethostbyname2_r :

#ifndef        INET6
  if(af == AF_INET6)
    return NSS_NOTFOUND;
#endif

As far as i have tested in a production environment it has no negative
side effects and when INET6 is defined some time in the future, it
is disabled anyway and lookup into LDAP with AF_INET6 requested, but
only IP4 address found, is being failed appropriately in the
_nss_ldap_parse_hostv6 function (through inet_pton failing - there
is a note in the man page of inet_pton, that they consider it a bug,
that "AF_INET6  does  not recognize IPv4 addresses" - hope, they won't
fix this "bug", if yes, in _nss_ldap_parse_hostv6 one should in my
opinion make sure, that inet_pton(AF_INET6,...) succeeds while
inet_pton(AF_INET,...) fails)


Version-Release number of selected component (if applicable):
nss_ldap-226-13.i386.rpm

How reproducible:
Always


Steps to Reproduce:
Case A:
1. ldap must be queried for host entries (in /etc/nsswitch.conf: hosts: files ldap dns)
2. restart nscd or invalidate the host cache, but let nscd cache (/etc/nscd.conf)
3. compile the attached program
4. run the program with the name of a host not in /etc/hosts, but in LDAP
5. see the output
Case B:
1. and 2. see above
3. run with a host, that is not in /etc/hosts: getent hosts <hostname>

Actual Results:
Case A:
prompt# ./gethostent2 cliff18
Official Name:
cliff18.muc.infineon.com
Aliases:
cliff18
IPv4 (found IPv6) Address:
172.23.4.92

Case B:
prompt# getent hosts cliff19
636c:6966:6631:3900:636c:6966:6631:3900 cliff19.muc.infineon.com 
prompt# getent hosts cliff19
172.23.4.17     cliff19.muc.infineon.com cliff19

(the 2nd time the output is ok)


Expected Results:
Case A:
Output:
Official Name:
cliff18.muc.infineon.com
Aliases:
cliff18
IPv4 (found IPv4) Address:
172.23.4.92

Case B:
expect correct output at first call of getent


Additional info: