Re: Forcing IPv4 DNS lookups first before IPv6

Russell Jones <rjones@xxxxxxxxxxxx> · Mon, 04 Apr 2011 11:34:25 -0500



    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@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos


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