Thanks for your help!

> Doubtful, if you are seeing AAAA lookups. Does "ip addr" show any IPv6 interfaces?

No active ipv6 interfaces:

[root@hostname1 ~]# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether 00:e0:81:76:ca:52 brd ff:ff:ff:ff:ff:ff
    inet 172.29.87.20/24 brd 172.29.87.255 scope global eth0
3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop qlen 1000
    link/ether 00:e0:81:76:ca:53 brd ff:ff:ff:ff:ff:ff


[root@hostname1 ~]# lsmod | grep -i ipv6
[root@hostname1 ~]#


> You *only* sees these for login? Perhaps some authentication module you are using is causing them to happen?


No, I also see this when doing traceroutes. It's just the "at login" part that it's most prevalent due to the DNS-induced lag time. The server's user authentication is NIS, and I am unaware of any IPv6 NIS configuration that would cause this. But if you are please do let me know, I'm tearing my hair out here and I don't have much left. Example from a traceroute from hostname1 to hostname2. This was nothing more than a "traceroute hostname2" on this same box I just showed as not having any IPv6 interfaces, nor the IPv6 kernel module loaded:


[root@hostname1 ~]# tcpdump -vvvvv 'port 53'
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes

11:07:24.989304 IP (tos 0x0, ttl  64, id 65039, offset 0, flags [DF], proto: UDP (17), length: 60) hostname1.59725 > vdns1-hc.example.com.domain: [bad udp cksum 2bd2!]  26130+ AAAA? hostname2.example.com. (32)
11:07:24.989612 IP (tos 0x0, ttl  62, id 61322, offset 0, flags [DF], proto: UDP (17), length: 111) vdns1-hc.example.com.domain > hostname1.59725:  26130* q: AAAA? hostname2.example.com. 0/1/0 ns: example.com. SOA[|domain]
11:07:24.989666 IP (tos 0x0, ttl  64, id 65040, offset 0, flags [DF], proto: UDP (17), length: 69) hostname1.47865 > vdns1-hc.example.com.domain: [bad udp cksum 9d73!]  33222+ AAAA? hostname2.ioexample.ioroot.tld. (41)
11:07:24.989763 IP (tos 0x0, ttl  64, id 65040, offset 0, flags [DF], proto: UDP (17), length: 72) hostname1.58021 > vdns1-hc.example.com.domain: [bad udp cksum f44f!]  24663+ PTR? 20.251.31.172.in-addr.arpa. (44)
11:07:24.990137 IP (tos 0x0, ttl  62, id 61323, offset 0, flags [DF], proto: UDP (17), length: 140) vdns1-hc.example.com.domain > hostname1.58021:  24663* q: PTR? 20.251.31.172.in-addr.arpa. 1/1/1 20.251.31.172.in-addr.arpa.[|domain]
11:07:24.991182 IP (tos 0x0, ttl  62, id 61324, offset 0, flags [DF], proto: UDP (17), length: 133) vdns1-hc.example.com.domain > hostname1.47865:  33222 NXDomain q: AAAA? hostname2.ioexample.ioroot.tld. 0/1/0 ns: ioexample.ioroot.tld. SOA[|domain]
11:07:24.991214 IP (tos 0x0, ttl  64, id 65041, offset 0, flags [DF], proto: UDP (17), length: 60) hostname1.42778 > vdns1-hc.example.com.domain: [bad udp cksum 5f4a!]  12333+ A? hostname2.example.com. (32)
11:07:24.991665 IP (tos 0x0, ttl  62, id 61325, offset 0, flags [DF], proto: UDP (17), length: 291) vdns1-hc.example.com.domain > hostname1.42778:  12333* q: A? hostname2.example.com. 1/6/5 hostname2.example.com. A hostname2.example.com ns: example.com.[|domain]
11:07:24.991797 IP (tos 0x0, ttl  64, id 65042, offset 0, flags [DF], proto: UDP (17), length: 71) hostname1.38670 > vdns1-hc.example.com.domain: [bad udp cksum 1a59!]  25903+ PTR? 43.43.29.172.in-addr.arpa. (43)
11:07:24.992089 IP (tos 0x0, ttl  62, id 61326, offset 0, flags [DF], proto: UDP (17), length: 137) vdns1-hc.example.com.domain > hostname1.38670:  25903* q: PTR? 43.43.29.172.in-addr.arpa. 1/1/1 43.43.29.172.in-addr.arpa.[|domain]
11:07:24.993030 IP (tos 0x0, ttl  64, id 65043, offset 0, flags [DF], proto: UDP (17), length: 72) hostname1.51119 > vdns1-hc.example.com.domain: [bad udp cksum 161e!]  53743+ PTR? 254.87.29.172.in-addr.arpa. (44)
11:07:24.993608 IP (tos 0x0, ttl  62, id 24219, offset 0, flags [DF], proto: UDP (17), length: 147) vdns1-hc.example.com.domain > hostname1.51119:  53743* q: PTR? 254.87.29.172.in-addr.arpa. 1/1/1 254.87.29.172.in-addr.arpa.[|domain]
11:07:24.993922 IP (tos 0x0, ttl  64, id 65044, offset 0, flags [DF], proto: UDP (17), length: 71) hostname1.49775 > vdns1-hc.example.com.domain: [bad udp cksum 6bab!]  59260+ PTR? 43.43.29.172.in-addr.arpa. (43)
11:07:24.994401 IP (tos 0x0, ttl  62, id 24220, offset 0, flags [DF], proto: UDP (17), length: 137) vdns1-hc.example.com.domain > hostname1.49775:  59260* q: PTR? 43.43.29.172.in-addr.arpa. 1/1/1 43.43.29.172.in-addr.arpa.[|domain]



Notice how before it even attempts an IPv4 lookup it cycles through IPv6 first, appending the domains that are in the "search" path of this boxes' /etc/resolv.conf to the host I did a traceroute to. Then after it exhausts all of its IPv6 lookup attempts, it does IPv4 and of course the first lookup succeeds. With boxes that have 3 or 4 domains on the search path, this causes a large amount unneeded IPv6 DNS traffic.

This behavior doesn't make a whole lot of sense, so I am hoping I'm missing something somewhere to force it to always do IPv4 DNS lookups first, or disable IPv6 lookups completely. All boxes' /etc/resolv.conf aren't special, just name server lines and then the "search" option with internal domains on it. We don't use IPv6 so don't need the functionality.

On similar CentOS 4 boxes with the same configuration on the same network, it does not attempt IPv6 lookups at all with traceroutes or SSH logins.



On 4/4/2011 10:50 AM, Adam Tauno Williams wrote: 
On Mon, 2011-04-04 at 09:51 -0500, Russell Jones wrote:

Hello!
I am having a strange issue with CentOS 5.4 that I cannot seem to solve.
Every DNS lookup results in AAAA records being requested first before A 
records. As a result, this causes a large amount of unnecessary DNS 
traffic on the network. IPv6 has been completely disabled on these servers:

Doubtful, if you are seeing AAAA lookups.  Does "ip addr" show any IPv6
interfaces?


/etc/modprobe.conf, ipv6 off and net-pf-10 off
/etc/sysconfig/network, NETWORKING_IPV6=no
lsmod | grep ipv6 shows the kernel module no longer loaded.
Yet watching TCP dump shows that AAAA records are requested before A 
records every time a login is requested from one of our local machines 
to another

You *only* sees these for login?  Perhaps some authentication module you
are using is causing them to happen?


 Is there some sort of configuration directive I can use to 
force IPv4 lookups first before IPv6? Or even better, stop IPv6 lookups 
all together?

I don't believe you see IPv6 lookups from the normal resolver libraries
unless there is at least one active IPv6 interface.

_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos