<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#ffffff">
Thanks for your help!<br>
<br>
> Doubtful, if you are seeing AAAA lookups. Does "ip addr" show
any IPv6 interfaces?<br>
<br>
No active ipv6 interfaces:<br>
<br>
[root@hostname1 ~]# ip addr<br>
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue<br>
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00<br>
inet 127.0.0.1/8 scope host lo<br>
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc
pfifo_fast qlen 1000<br>
link/ether 00:e0:81:76:ca:52 brd ff:ff:ff:ff:ff:ff<br>
inet 172.29.87.20/24 brd 172.29.87.255 scope global eth0<br>
3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop qlen 1000<br>
link/ether 00:e0:81:76:ca:53 brd ff:ff:ff:ff:ff:ff<br>
<br>
<br>
[root@hostname1 ~]# lsmod | grep -i ipv6<br>
[root@hostname1 ~]#<br>
<br>
<br>
> You <b class="moz-txt-star"><span class="moz-txt-tag">*</span>only<span
class="moz-txt-tag">*</span></b> sees these for login? Perhaps
some authentication module you are using is causing them to happen?<br>
<br>
<br>
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:<br>
<br>
<br>
<tt>[root@hostname1 ~]# tcpdump -vvvvv 'port 53'<br>
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture
size 96 bytes<br>
<br>
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)<br>
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]<br>
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)<br>
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)<br>
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]<br>
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]<br>
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)<br>
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]<br>
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)<br>
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]<br>
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)<br>
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]<br>
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)<br>
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]</tt><br>
<br>
<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
<br>
<br>
On 4/4/2011 10:50 AM, Adam Tauno Williams wrote:
<blockquote cite="mid:1301932238.3430.13.camel@linux-yu4c.site"
type="cite">
<pre wrap="">On Mon, 2011-04-04 at 09:51 -0500, Russell Jones wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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:
</pre>
</blockquote>
<pre wrap="">
Doubtful, if you are seeing AAAA lookups. Does "ip addr" show any IPv6
interfaces?
</pre>
<blockquote type="cite">
<pre wrap="">/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
</pre>
</blockquote>
<pre wrap="">
You *only* sees these for login? Perhaps some authentication module you
are using is causing them to happen?
</pre>
<blockquote type="cite">
<pre wrap=""> 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?
</pre>
</blockquote>
<pre wrap="">
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
<a class="moz-txt-link-abbreviated" href="mailto:CentOS@centos.org">CentOS@centos.org</a>
<a class="moz-txt-link-freetext" href="http://lists.centos.org/mailman/listinfo/centos">http://lists.centos.org/mailman/listinfo/centos</a>
</pre>
</blockquote>
</body>
</html>