[CentOS] Forcing IPv4 DNS lookups first before IPv6

Mon Apr 4 16:34:25 UTC 2011
Russell Jones <rjones at eggycrew.com>

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>