Bug 134128 - Domain name is appended to LDAP Server's FQDN when doing a DNS lookup
Domain name is appended to LDAP Server's FQDN when doing a DNS lookup
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: nss_ldap (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Nalin Dahyabhai
: Reopened
Depends On:
  Show dependency treegraph
Reported: 2004-09-29 14:59 EDT by James Trater
Modified: 2007-11-30 17:07 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-10-19 15:17:23 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description James Trater 2004-09-29 14:59:16 EDT
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):

How reproducible:

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:
Comment 1 James Trater 2004-09-30 12:43:55 EDT
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)?
Comment 2 Ulrich Drepper 2004-10-01 02:26:11 EDT
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.
Comment 3 James Trater 2004-10-01 09:46:13 EDT
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:  Bcast:  
          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:  Mask:
          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. 

Comment 4 Ulrich Drepper 2004-10-01 14:45:00 EDT
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.
Comment 5 Red Hat Bugzilla 2007-02-05 14:27:32 EST
REOPENED status has been deprecated. ASSIGNED with keyword of Reopened is preferred.
Comment 6 RHEL Product and Program Management 2007-10-19 15:17:23 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.