[FreeBSD 7.0-BETA1] strange behavior in hostname resolving order
JINMEI Tatuya / 神明達哉
jinmei at isl.rdc.toshiba.co.jp
Mon Nov 5 07:31:33 UTC 2007
At Sat, 03 Nov 2007 00:05:07 +0900,
Byung-Hee HWANG <bh at izb.knu.ac.kr> wrote:
> Usually i prefer 6to4(stf(4)) to 6over4(gif(4)) because some
> tunnel providers like to limit bandwidth too musch. So until my
> upstream ISP give me native ipv6 addresses (it's take long time maybe),
> i'm going to use 6to4 instead of 6over4 continuous.
(snip)
> And from now on, i would give you one question. Why is 7.0-BETA1
> different from another -RELEASE in hostname resolving order? AFAIK, at
> least on 6.2-RELEASE, the order is first IPv6 and then IPv4. However,
> 7.0-BETA1 try to lookup in first IPv4 than IPv6. Here is the evidence:
This is most likely because 7.0 now installs the address selection
policy table at boot time by default:
http://www.freebsd.org/cgi/cvsweb.cgi/src/etc/defaults/rc.conf.diff?r1=1.304&r2=1.305
Now if you have (which I guess is your network configuration)
A. a global IPv4 address and
B. a 6to4 IPv6 address,
and have a candidate destination addresses
C. a global IPv4 address (like 210.226.20.15)
D. a native global IPv6 address (like 2001:218:422:1::15)
then getaddrinfo() will prefer the combination of {A and C} because
these addresses have a matching scope while B and D don't. If you
make sure the 6to4 source address always wins, you should modify the
policy table to:
Prefix Precedence Label
::1/128 50 0
::/0 40 1
2002::/16 30 1
::/96 20 3
::ffff:0:0/96 100 4
(i.e., change the label of 2002::/16).
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
jinmei at isl.rdc.toshiba.co.jp
More information about the bind-users
mailing list