Red Hat Bugzilla – Bug 134128
Domain name is appended to LDAP Server's FQDN when doing a DNS lookup
Last modified: 2007-11-30 17:07:04 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7)
Description of problem:
We use an openLDAP directory to store user and group information. The
LDAP server is specified in the config file as:
I have also tried using:
No matter which way I specify the LDAP server, when the machine does a
lookup on the server's IP address, it appends the domain name to the
If I do a picket sniff, I see that it requests the IP address for:
ldap1.example.com.example.com . The DNS server will return a No Such
Domain error, and the client will try the query again - this time with
the correct name (ldap1.example.com)
I have tried various combinations of domain and search in resolv.conf,
and the error still occurs. If I do an nslookup on ldap1.example.com,
it works correctly.
nsswitch is configured to look in file and then DNS for host entries
(there is NOT an entry for the LDAP server in /etc/hosts)
The Beta for RedHat Enterprise 4 also has this problem.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Configure your machine to be an LDAP client
2. Query the LDAP server (by logging in, doing an id username, etc.)
3. If you capture the packets or log requests on the DNS server, you
will see that the domain name is appended to the LDAP Server's FQDN
when doing a DNS lookup.
Actual Results: LDAP queries still work, but extra DNS requests are
made and extra network traffic is generated.
Expected Results: When doing a DNS lookup to get the LDAP Server's IP
address, the FQDN should be used and NOT the (FQDN + the domain name)
Upon further review, this looks to be a glibc bug. I used a better
packet sniffer, and every DNS query first looks for an AAAA (ipv6)
record. When that doesn't work, it appends every domain name in the
search list and does a query. Finally, it looks for an A record -
which succeeds. Is there any way to disable the ipv6 look ups (these
systems aren't using ipv6)?
The behavior you see is correct. If IPv6 is enabled on any interface,
a query which does not have the protocol specified looks up IPv6 and
IPv6 addresses. To disable this you must prevent IPv6 addresses to be
assigned. Even just loading the IPv6 module causes link local
addresses to be added. So it is necessary to prevent the module to be
added. You can add
alias net-pf-10 off
Since the IPv6 lookup you say is the problem, I'm closing the bug.
It's a configuration issue, nothing wrong with the code.
Even with ipv6 disabled, I still see this behavior.
On the client:
[jamest@re39 jamest]$ /sbin/lsmod | grep ipv6
[jamest@re39 jamest]$ cat /etc/modules.conf
alias eth0 3c59x
alias net-pf-10 off
[jamest@re39 jamest]$ /sbin/ifconfig
eth0 Link encap:Ethernet HWaddr 00:04:76:CC:CF:1E
inet addr:192.168.1.39 Bcast:192.168.1.255
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:2472 errors:0 dropped:0 overruns:0 frame:0
TX packets:1808 errors:0 dropped:0 overruns:0 carrier:0
RX bytes:1224527 (1.1 Mb) TX bytes:264473 (258.2 Kb)
Interrupt:3 Base address:0xd400
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:1895 errors:0 dropped:0 overruns:0 frame:0
TX packets:1895 errors:0 dropped:0 overruns:0 carrier:0
RX bytes:130127 (127.0 Kb) TX bytes:130127 (127.0 Kb)
This is what I see on the DNS server when I do a tcpdump ( I
appologize for the line wraps):
08:40:22.734067 re39.cluster.net.32770 > cygnus.cluster.net.domain:
? ldap.cluster.net. (34) (DF)
08:40:22.734548 cygnus.cluster.net.domain > re39.cluster.net.32770:
0 (91) (DF)
08:40:22.734859 re39.cluster.net.32770 > cygnus.cluster.net.domain:
? ldap.cluster.net.cluster.net. (46) (DF)
08:40:22.735339 cygnus.cluster.net.domain > re39.cluster.net.32770:
ain* 0/1/0 (103) (DF)
08:40:27.730875 re39.cluster.net.32770 > cygnus.cluster.net.domain:
23961+ A? l
dap.cluster.net. (34) (DF)
Notice that it does an ipv6 lookup (which it shouldn't do because
ipv6 is disabled on the client) then it does an ipv6 lookup with the
domain appened, and finally it does the (correct) ipv4 lookup.
This is most likely not a glibc issue. getaddrinfo will only examine
the available interfaces if the application or a library passed the
AI_ADDCONFIG flag to getaddrinfo. Unfortunately this feature has to
be enabled explicitly.
So, determine which application causes the lookups. Is it nss_ldap?
If yes, change the component name appropriately to reach the
REOPENED status has been deprecated. ASSIGNED with keyword of Reopened is preferred.
This bug is filed against RHEL 3, which is in maintenance phase.
During the maintenance phase, only security errata and select mission
critical bug fixes will be released for enterprise products. Since
this bug does not meet that criteria, it is now being closed.
For more information of the RHEL errata support policy, please visit:
If you feel this bug is indeed mission critical, please contact your
support representative. You may be asked to provide detailed
information on how this bug is affecting you.