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