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) Gecko/20040729 Firefox/0.9.2 Description of problem: We use an openLDAP directory to store user and group information. The LDAP server is specified in the config file as: uri ldap://ldap1.exmaple.com/ I have also tried using: uri ldap://ldap1.example.com uri ldap://ldap1.example.com:389 host ldap1.example.com:389 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 server's FQDN. 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): nss_ldap-207-11 How reproducible: Always 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) Additional info:
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 to /etc/modules.conf. 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]$ [jamest@re39 jamest]$ cat /etc/modules.conf alias eth0 3c59x alias net-pf-10 off [jamest@re39 jamest]$ [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 Mask:255.255.255.0 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 collisions:0 txqueuelen:1000 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 collisions:0 txqueuelen:0 RX bytes:130127 (127.0 Kb) TX bytes:130127 (127.0 Kb) [jamest@re39 jamest]$ 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: 23959+ AAAA ? ldap.cluster.net. (34) (DF) 08:40:22.734548 cygnus.cluster.net.domain > re39.cluster.net.32770: 23959* 0/1/ 0 (91) (DF) 08:40:22.734859 re39.cluster.net.32770 > cygnus.cluster.net.domain: 23960+ AAAA ? ldap.cluster.net.cluster.net. (46) (DF) 08:40:22.735339 cygnus.cluster.net.domain > re39.cluster.net.32770: 23960 NXDom 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 responsible party.
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: http://www.redhat.com/security/updates/errata/ 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.