10

UPDATE:

BIND Version:

[[email protected]] $ named -v
BIND 9.3.6-P1-RedHat-9.3.6-16.P1.el5

Operating System:

CentOS release 5.6 (Final)

After running [[email protected]] $ 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:

[[email protected] ~] # 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!

3
  • 2
    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, 2011 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, 2011 at 16:43
  • 1
    Did you run rndc reconfig after changing the config on the master?
    – Cakemox
    Aug 29, 2011 at 8:30

3 Answers 3

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?

3
  • 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, 2011 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, 2011 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, 2011 at 6: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.

1
  • 1
    Good ol' chroot. Glad you found it.
    – dmourati
    Aug 30, 2011 at 4:24
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.

  1. Make sure your clocks are both up to date (at least within a reasonable margin) on both servers.

  2. You may have SELinux interfering. Try disabling it temporarily to test.

2
  • 1
    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, 2011 at 6:51
  • Check my answer for an update.
    – bahamat
    Aug 29, 2011 at 15:36

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .