Zone transfer not working
JINMEI Tatuya / 神明達哉
jinmei at isl.rdc.toshiba.co.jp
Fri Oct 6 08:51:37 UTC 2006
>>>>> On Thu, 5 Oct 2006 11:22:21 +0200 (CEST),
>>>>> "Michael Bleyer" <mike at hoc.net> said:
> my zone transfer does not work and I would appreciate some help.
> Setup:
> Master: (80.190.246.175)
> acl partners { 85.214.66.29; };
> zone "linksabbieger.net" in {
> type master;
> file "linksabbieger.net.zone";
> allow-query { any; };
> notify yes;
> allow-transfer { partners; };
> };
[snip]
> So afaik, this setup should work. But I get error messages on master and
> slave:
> Master says:
> Oct 5 08:27:24 ombelico named[20052]: security: client
> ::ffff:85.214.66.29#40793: zone transfer 'linksabbieger.net/IN' denied
This is a well-known issue of BIND 9.2 running on a certain type of OS
(e.g., Linux). Possible workarounds are:
1. update BIND to 9.3 (or later)
2. set match-mapped-addresses to yes in the options statement of
named.conf:
match-mapped-addresses yes;
3. disable listening on IPv6 addresses if you don't use IPv6
Assuming you want to play with IPv6 (since listen-on-ipv6 is disabled
by default, which seems to indicate you explicitly turn it on), I
personally recommend option 1, since this is just one common case of a
more general issue in using IPv4-mapped IPv6 addresses
(::ffff:xx.yy.zz.ww) as described in the following (old but still
useful) document:
ftp://www.kame.net:ftp/pub/internet-drafts/draft-cmetz-v6ops-v4mapped-api-harmful-01.txt
Trying to work around one specific problem while using the risky API
(i.e., option 2) may cause another surprising trouble in the future.
BIND 9.3 avoids the trouble at the API level (by using newer API) and
should provide more deterministic and safer behavior.
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