allow-transfer from slave server

Kevin Darcy kcd at daimlerchrysler.com
Tue Apr 25 00:12:18 UTC 2006


Ronni Jensen wrote:

>Hi,
>
>I have a master (ns0) and 2 slave servers (ns1 & ns2).
>
>ns0 is not accessible from WAN, and only allows zone tranfers to ns1 and
>ns2 on RFC1918 addresses.
>ns1 and ns2 are accessible from outside, where a WAN public IP is NAT'ed
>to their local IP-address.
>
>On a server (123.123.123.123) at another location, I want to pull zones
>from either ns1 or ns2.. I have this config on ns1:
>
>zone "example.dk" IN {
>        type slave;
>        file "/var/named/slave/slave.example.dk";
>        masters { 10.10.10.2; };   // this is the master server (ns0)
>        allow-transfer { 123.123.123.123; }; // this is the outside
>server which want to pull the zone
>};
>
>..But when I initiate a zone transfer from 123.123.123.123 which has
>this config in named.conf:
>
>zone "example.dk" IN {
>        type slave;
>        file "/etc/bind/data/slave.example.dk";
>        masters { 111.111.111.111; }; // this is ns1's public IP-address
>};
>
>..I get this error in my activity log:
>
>24-Apr-2006 11:40:45.659 general: info: zone example.dk/IN: Transfer
>started.
>24-Apr-2006 11:40:45.695 xfer-in: info: transfer of 'example.dk/IN' from
>111.111.111.111#53: connected using 123.123.123.123#32778
>24-Apr-2006 11:40:45.761 xfer-in: error: transfer of 'example.dk/IN'
>from 111.111.111.111#53: failed while receiving responses: REFUSED
>24-Apr-2006 11:40:45.761 xfer-in: info: transfer of 'example.dk/IN' from
>111.111.111.111#53: end of transfer
>
>Can you tell me why I get that error? :-/
>
Looks in the logs on the master to verify that the source address it 
sees is 123.123.123.123. It _should_ be, of course, but when dealing 
with NAT, sometimes things get screwy and the source address of a packet 
is an unexpected one.

The only other thing that comes to mind is that some firewall or 
intrusion-prevention system in between your master and your Internet 
client is faking the REFUSED response itself. Again, it should be 
helpful in this situation to look at the logs on the master -- query 
logs -- to verify that the query actually got there.

- Kevin




More information about the bind-users mailing list