Question: How can I disable inet6 AAAA queries for my LDAP server during (LDAP-backed) NSS lookups on a CentOS (RHEL) 5 machine?
Background: I've servers configured to consult ldap://ldap.internal
for NSS passwd and group lookups. Every relevant NSS lookup, for example the getpwuid(3) implied by an ls -l
which needs to translate UIDs to network user names, performs the following DNS dance before connecting to the ldap server:
AAAA? ldap.internal -> (no records)
AAAA? ldap.internal.internal -> NXDomain
A? ldap.internal -> 192.168.3.89
I'd like to skip the first two queries completely. Configuration:
[server]$ cat /etc/redhat-release
CentOS release 5.4 (Final)
[server]$ grep ^passwd /etc/nsswitch.conf
passwd: files ldap
[server]$ grep ^uri /etc/ldap.conf
uri ldap://ldap.internal/
For what it's worth, IPv6 support is otherwise disabled on these systems:
[server]$ grep off /etc/modprobe.conf
alias ipv6 off
alias net-pf-10 off
[server]$ echo "$(ip a | grep -c inet6) IPv6-enabled interfaces"
0 IPv6-enabled interfaces
I'm not sure if
/etc/gai.conf
would have been available in 2009, but it is now (and would appear to have been at least since CentOS 5.5). It is a feature of glibc and allows setting the preference for sorting of IP addresses bygetaddrinfo(3)
.Look at https://serverfault.com/a/511240/161782 for a full answer with examples.
If you also want to make source address selection have a matching policy, see this post: http://biplane.com.au/blog/?p=122
The brief answer is: no, this behavior cannot be changed by simple system configuration.
AAAA lookups are the expected behavior of the shipped openldap libraries, openldap-2.3.43-3.el5 at the time of this writing. Built with --enable-ipv6, the LDAP connection routines resolve hosts with
getaddrinfo(3)
looking for any available address family (AF_UNSPEC
), and so including both inet4 and inet6.Now, the openldap code is aware of the
AI_ADDRCONFIG
hint, which would prevent looking for inet6 addresses when none are configured on the system, and similarly for inet4 addresses. However, the code fails to supply this hint for two reasons:First, and buggily, the hint is misspelled as "AI_ATTRCONFIG" [sic], which misspelling is corrected around 2.4.14. Second, there is no configure test for the viability of this flag, so the code which would supply the flag, misspelled or not, is never compiled in.
Just a little more unneeded network chatter to live with, I suppose.