IBM Link: Client on AIX generates excessive IPV6 DNS lookups for new connections

Problem(Abstract)

Very slow network traffic on IBM Tivoli Directory Server 5.x or 6.x on an AIX system might occur because the client generates excessive IPV6 DNS lookups for every new connection it makes even if IPV6 is not enabled.

Resolving the problem

An IBM Tivoli Directory Server version 5.x or 6.x client on AIX generates excessive IPV6 DNS lookups for every new connection it makes, even if IPV6 is not enabled on the client computer or if the numeric address is used. This can cause performance on the network to be very slow.
To fix this problem, disable IPV6 lookups on the client computer by adding the following line to the /etc/netsvc.conf file:

hosts=local4,bind4

To determine whether this is the cause of the network performance problem, you can run an iptrace on the client computer, as follows:

# iptrace -a ./iptrace.out
# ldapsearch -h {any valid IPV4 address or hostname} -s base objectclass=*
# ps -ef | grep iptrace
# kill {PID of the iptrace process; do not kill -9}
Then view the iptrace.out file in Ethereal or use the ipreport command to format the trace.

For example:

Suppose you have an AIX system using an IBM Tivoli Directory Server client with the following configuration:

/etc/resolv.conf file:

nameserver      192.168.1.2
nameserver      192.168.1.3
domain  example.austin.texas.com
search  example.austin.texas.com austin.texas.com texas.com

/etc/netsvc.conf file:

(default – no settings, just comments)

/etc/hosts file:

127.0.0.1       loopback localhost    # loopback (lo0) name/address
192.168.1.100   client                # client.example.austin.texas.com
192.168.1.255   ldap                  # ldap.austin.texas.com

Run the following command:

ldapsearch -h ldap.austin.texas.com -s base objectclass=*

The command generates the following DNS traffic:

No.  Time       Source         Destination    Pro  Info
184  33.397930  192.168.1.100  192.168.1.2    DNS  query A
   ldap.austin.texas.com

187  33.400709  192.168.1.2    192.168.1.100  DNS  response A
   192.168.1.255

188  33.400816  192.168.1.100  192.168.1.2    DNS  query AAAA
   ldap.austin.texas.com

189  33.403248  192.168.1.2    192.168.1.100  DNS  response,
   No such name

190  33.403346  192.168.1.100  192.168.1.2    DNS  query AAAA
   ldap.austin.texas.com.example.austin.texas.com

191  33.403660  192.168.1.2    192.168.1.100  DNS  response,
   No such name

192  33.403723  192.168.1.100  192.168.1.2    DNS  query AAAA
   ldap.austin.texas.com.austin.texas.com

193  33.406166  192.168.1.2    192.168.1.100  DNS  response,
   No such name

194  33.406225  192.168.1.100  192.168.1.2    DNS  query AAAA
   ldap.austin.texas.com.texas.com

198  40.414418  192.168.1.2    192.168.1.100  DNS  response,
   No such name

The first query (184) is a normal IPV4 lookup for “ldap.austin.texas.com“, which returns “192.168.1.255“. But then an IPV6 lookup is done for the same name. Because there is no IPV6 address for ldap.austin.texas.com, it continues searching every search domain in the resolv.conf file (example.austin.texas.com austin.texas.com texas.com) trying to find one.