Bind zone transfer refused

Question

UPDATE:

BIND Version:

[root@10.224.45.130] $ named -v
BIND 9.3.6-P1-RedHat-9.3.6-16.P1.el5

Operating System:

CentOS release 5.6 (Final)

After running [root@10.224.45.131] $ dig @10.224.45.130 example.com. axfr:

Slave:

; <<>> DiG 9.3.6-P1-RedHat-9.3.6-16.P1.el5 <<>> @10.224.45.130 example.com. axfr
; (1 server found)
;; global options:  printcmd
; Transfer failed.

Master:

28-Aug-2011 12:29:01.384 client 10.224.45.131#60553: query: example.com IN AXFR -
28-Aug-2011 12:29:01.384 client 10.224.45.131#60553: zone transfer 'example.com/AXFR/IN' denied

Same error message as before.

UPDATE 2:

[root@10.224.45.130 ~] # iptables -L -n -v
Chain INPUT (policy DROP 30235 packets, 1747K bytes)
 pkts bytes target     prot opt in     out     source               destination         
 171K   23M ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0           
    0     0 ACCEPT     all  --  tun0   *       0.0.0.0/0            0.0.0.0/0           
    0     0 ACCEPT     all  --  tap0   *       0.0.0.0/0            0.0.0.0/0           
57196 6930K ACCEPT     all  --  br0    *       0.0.0.0/0            0.0.0.0/0           
  688 57376 ACCEPT     icmp --  *      *       0.0.0.0/0            0.0.0.0/0           icmp type 8 
37869 6120K ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED 
  392 21216 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:22 
    1    64 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:53 
   74  5275 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0           udp dpt:53 
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:80 
    1    64 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:110 
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:143 
    3   192 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:389 
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:443 
    1    64 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:465 
    1    64 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:587 
   13   832 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:636 
    0     0 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0           udp dpt:694 
    1    64 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:843 
    1    64 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:873 
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:953 
  119  7584 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:993 
    0     0 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0           udp dpt:993 
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:1194 
    0     0 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0           udp dpt:1194 
    1    48 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:3306 
    1    64 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:5901 
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            10.224.45.130       tcp dpt:10000 
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:11211 
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:11212 
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:11213 
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:11511 
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:11512 
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:11513 

Chain FORWARD (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
 2987  372K ACCEPT     all  --  br0    *       0.0.0.0/0            0.0.0.0/0           
    0     0 ACCEPT     all  --  *      br0     0.0.0.0/0            0.0.0.0/0           
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:80 
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:443 

Chain OUTPUT (policy ACCEPT 246K packets, 37M bytes)
 pkts bytes target     prot opt in     out     source               destination

I've probably looked at every single page regarding BIND master/slave setup, and I cannot for the life of me get the zone transfer working.

Here's my setup: (scroll down for description of problem)

Master: 10.224.45.130

/etc/named.conf

options {
    directory "/var/named";
    version "unknown";
    pid-file "/var/run/named/named.pid";
    recursion yes;
    allow-recursion { localhost; localnets; };
    notify explicit;
    allow-transfer {
        10.224.45.131;
    };
    also-notify {
        10.224.45.131;
    };
};

zone "." {
    type hint;
    file "named.root";
};

zone "example.com" IN {
    type master;
    file "data/example.com.hosts";
};

Slave: 10.224.45.131

/etc/named.conf

options {
    directory "/var/named";
    version "unknown";
    pid-file "/var/run/named/named.pid";
    recursion yes;
    allow-recursion { localhost; localnets; };
    notify yes;
    allow-transfer { "none"; };
    allow-notify {
        10.224.45.130;
    };
};

zone "." {
    type hint;
    file "named.root";
};

zone "example.com" IN {
    type slave;
    file "slaves/example.com.hosts";
    masters {
        10.224.45.130;
    };
};

Here's the problem. When I restart named on the slave server it sees that the zone files do not exist yet and requests a transfer from the master server:

named.log (Slave)

[10.224.45.131] zone example.com/IN: no database exists yet, requesting AXFR of initial version from 10.224.45.130#53

...after which the master server receives the transfer request:

named.log (Master)

[10.224.45.130] client 10.224.45.131#53467: query: example.com IN AXFR -

...and replies with the transfer request, which gets denied:

named.log (Master)

[10.224.45.130] client 10.224.45.131#53467: zone transfer 'example.com/AXFR/IN' denied

...on the slave server it shows up as being REFUSED:

named.log (Slave)

[10.224.45.131] transfer of 'example.com/IN' from 10.224.45.130#53: failed while receiving responses: REFUSED

Looking at all the configs over and over I can't find anything wrong with the settings. I have the master server's IP address listed in the masters setting of the slave zone configuration, I have the slave server's IP address listed in the allow-transfer setting of the master options settings.

All the IP addresses are what they should be, it's not like it's trying to use the public IP address and being rejected because the IP address doesn't match. I have iptables setup to allow TCP/UDP connections on port 53 (and 953) on both servers. I have setup the file permissions properly so that the /slaves directory where the slave zone files are stored is writable by the named user.

No matter what I do I always get this same error. If anyone can give me a clue as to what I'm missing I would really appreciate it!

Have you tried (temporarily) setting `allow-transfer` to `any` to see if that fixes the issue? Your `allow-transfer` clause looks correct, but this will eliminate any chance of problems... — voretaq7, Aug 28 '11 at 16:12
Nope, still getting the same error. I also just tried adding the master server's WAN IP address to the 'masters' setting, just in case, and that didn't fix it either. — Sarah Ryan, Aug 28 '11 at 16:43
Did you run `rndc reconfig` after changing the config on the master? — Cakemox, Aug 29 '11 at 08:30

score 3 · Answer 1 · answered Aug 28 '11 at 19:06

3

To start, try verifying that a zone transfer works.

On the slave, issue dig @master your-domain. axfr

What versions of BIND and what OS?

answered Aug 28 '11 at 19:06

dmourati

24,720
2
40
69

I've updated my question with the output and logs of this command. It shows it as being denied just like in the regular zone transfer request. I've also added information regarding versions and OS. Sorry for leaving that important information out. – Sarah Ryan Aug 28 '11 at 19:38
1

OK, so the fact that the dig command fails indicates that there is still a problem on the master. @voretaq7 above suggested allow-transfer to any which I agree is a reasonable troubleshooting step. Add localhost to allow-transsfer, try the dig command from the master at localhost. Also setup a "tcpdump -i any port 53" on master to verify the source/destination IP addresses. You say "I have iptables setup to allow TCP/UDP connections on port 53 (and 953) on both servers" but please add the output of "iptables -L -n -v" on the master. That or shut down iptables on the master and retest. – dmourati Aug 28 '11 at 20:03
I've added localhost (as well as all other hostnames and IP addresses it could possibly be) to the allow-transfer setting and I'm still getting the same error. I've added the output from the iptables command you requested, as well as having iptables disabled while trying again. Still no luck. – Sarah Ryan Aug 29 '11 at 06:49

score 3 · Accepted Answer · answered Aug 29 '11 at 16:49

3

Found the problem. I am using a chrooted BIND, but I was editing the conf files in /etc and not /var/named/chroot/etc. So the changes that I was making were not being seen. I copied the conf files to the chroot directory and it all works fine now.

answered Aug 29 '11 at 16:49

Sarah Ryan

251
1
3
11

1

Good ol' chroot. Glad you found it. – dmourati Aug 30 '11 at 04:24

bahamat · Answer 3 · 2011-08-29T15:41:49.000

1

It may seem like this is already covered by the allow-transfer statement in options, but try adding an explicit allow-transfer statement under the zone.

I don't really see anything wrong with your config. It looks like it should work. Is bind listening on that port at all? (I.e., do any requests succeed? Or do they all fail?)

Well, I've got two more ideas worth trying.

Make sure your clocks are both up to date (at least within a reasonable margin) on both servers.
You may have SELinux interfering. Try disabling it temporarily to test.

edited Aug 29 '11 at 15:41

answered Aug 28 '11 at 20:52

bahamat

6,193
23
28

I've tried putting the allow-transfer option in the zone config and it's still giving me the same error. It's only transfer requests that fail. I can successfully query the server for any record type and it'll return it as expected. But when I try to do the zone transfer I get denied/REFUSED error messages. – Sarah Ryan Aug 29 '11 at 06:51
Check my answer for an update. – bahamat Aug 29 '11 at 15:36

Bind zone transfer refused

3 Answers3