BIND9 don't query specific nameserver with IPv4 address.

[Daisuke Koike]

Jinmei-san,

From: JINMEI Tatuya / 神明達哉 <jinmei at isl.rdc.toshiba.co.jp>
Date: Thu, 24 Jun 2004 00:37:33 +0900

> I guess there are no meaningful IPv6 routes (particularly including
> the default route) in the server machine.

Exactly so.


> Based on the assumption, it seems the following steps happened:
> 
> 1. the cache server gets the A and AAAA RRs for widefw.csl.sony.co.jp.
> 2. when the first time the server tries to send queries to widefw, it
>    sets up ADB entries for both the IPv4 and IPv6 addresses.  RTTs for
>    the addresses are randomly initialized.
> 3. a query is sent to the address that has a smaller initial RTT.  In
>    the problematic case, it's the IPv6 address.
> 4. since the server does not have a route to the destination, sending
>    the UDP query immediately fails (at least on a BSD box), and so the
>    server records the error in the corresponding socket event.
> 5. the server then immediately cancels the query session (see line 689
>    of lib/dns/resolver.c)
> 6. however, the ADB entries are intact according to the logic of
>    resolver.c:fctx_cancelquery() in this context.  Thus, the
>    preference between the two ADB entries do not change despite the
>    failure.
> 7. eventually, a timeout at the fctx level occurs, and steps from 3 to
>    6 are repeated.
> 8. there are actually several chances to reset the ADB entries
>    according to the log.  Unfortunately, however, the IPv6 address
>    gets the smaller initial RTT every time in this session.
> 9. finally, dig gives up waiting a response.

It makes sense.
I think, it occurs under certain conditions as follows.

a. The OS supports IPv6.
   (on the FreeBSD, it is default)

b. BIND9 was compiled with IPv6 support. 
   (depends on IPv6 settings on the OS. Currently, it seems that
    "--disable-ipv6" option doesn't have effect)

c. All(or only) nameservers of the domain which it tries to resolve are
   assigned both A and AAAA records on parent zone.


> This is definitely a bad behavior, can happen for many other users, so
> we need to provide a way to mitigate the problem (at least).

I'm of the same sentiment. Some workarounds are here:

1. Remove inet6 address on all the interfaces
                  or
   Remove IPv6 support on that OS

   and then, re-compile bind.
   (to restart bind is effective only as a temporary countermeasure)

2. patching your fix to bind.

3. Add a nameserver which has only A record to the zone authority.
   (may be another name of existing server)

I did 1.
Then, the problem isn't reproducing now.

And also, I'll send report to bind9-bugs.

Many thanks!

----------------------------------------
Daisuke Koike 	<daisukek at tkd.att.ne.jp>