Thanks for your help! > Doubtful, if you are seeing AAAA lookups. Does "ip addr" show any IPv6 interfaces? No active ipv6 interfaces: [root at 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 at hostname1 ~]# lsmod | grep -i ipv6 [root at 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 at 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 at centos.org > http://lists.centos.org/mailman/listinfo/centos > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.centos.org/pipermail/centos/attachments/20110404/57e726b2/attachment-0005.html>