Secondary DNS zone transfers fail with new DLink router...

Did this work before you got the local firewall? If so that means that the IPtables firewall on the primary and the configuration of the primary allows the zone transfer. So the would have to be with the new firewall. Have you configured the D-Link to port forward 53/UDP & 53/UDP to your secondary server and allow inbound traffic on both ports?

actually I believe that zone transfers take place on 53/TCP, only the name resolution uses udp. Try this iptables rule to let it through:

/sbin/iptables -A INPUT -s xxx.xxx.xxx.xxx -p tcp -m tcp --dport 53 -j ACCEPT

just make sure you substitute the xxx.xxx.xxx.xxx for the ip of the primary nameserver.

The zone transfers worked before I installed the local firewall.  In fact I am receiving zone transfers from two different primaries for various domains on the secondary server.  I have configured the D-Link to allow and port forward 53/UDP and 53/TCP to my secondary sever ( 192.168.0.3 ).   ( DLINK FIREWALL = Allow Virtual Server DNS WAN,* LAN,192.168.0.3 IP (0),53  )

The port forwarding works fine because the secondary can resolve domainnames without any problem.  it's just when a DNS zone transfer initiates, it times out with the primary...

This is also true for the other primary that I am receiving zone updates for, so it has to be a D-Link configuration problem, unless both primaries are also affected.

The way I read the RFC it looks to me like zone transfers will always use 53/TCP. I don't know if the DLINK "FIREWALL = Allow Virtual Server DNS" makes both 53/UDP and 53/TCP usable. One check to see if that's the problem would be to run a sniffer trace on one of the primaries (restricted to the external IP of your D-Link) when you attempt a zone transfer. If you see the primary reply to the request on 53/TCP that might imply that D-Link isn't allowing that inbound.

If the "secondary" machine is "behind" the firewall, you should not need any rules in the D-Link to allow the zone transfer. The connection will be originated by the secondary, and because it's stateful (TCP), the D-Link will pass the traffic fine.

I would suspect that somewhere along the line, your IP Address changed and the "primary" server will need to be reconfigured to support the new address.

I thought of that, but the error should then have been "access denied" rather than a time out on the AXFR. Also the primaries should be logging a transfer denied to that IP.

A quick, and easy way, to test would be to go the machine behind the firewall, and try to telnet to port 53 on the primary server. While the telnet is running, run "netstat -na | grep ":53" in another terminal and check the state of the connection.

Another thing could be if on of the servers has a typo in the named.conf file(like a missing ; on the primary for allowed-transfer settings). This would keep the communications from happening properly.

doing the telnet and netstat showed an ESTABLISHED connection on the primary server...

I've looked at the config files and they look fine on both the primary and secondary servers...

I've got the most recent firmware update from D-link for the router as well.

What IP Address was shown on the primary as ESTABLISHED to? Is this IP Address listed in the /etc/named.conf file for the zone you are trying to transfer? Are there other addresses? Are there semicolons (;) after each address and after the closing } on the configuration line?

I think at this point you need to do a 'tcpdump -w /tmp/sniff.trace host IP-of-secondary'' on a primary when you do a zone transfer from the secondary. The using 'tcpdump -n -r /tmp/sniff.trace' will tell you if the zone transfer request reaches the primary and whether it sends return data. If you see both the request and the reply (which I think you probably will since it did work before) the problem is l;ikely to be in the D-Link.

One other possibility could be that the failure is IP related. While the source IP of the zone transfer request will be that of the outside IP of the D-Link it might be that the real IP of the secondary is in the data payload of the request. If that were to be the case you'd see the denied message in the logs on the primary server.

Hmm... upon further inspection I am noticing that my secondary is having various other troubles which were not present after installing the D-Link firewall/router.   I need to address these problems first and see if it doesn't fix the zone transfers.  

Using tcpdump did not show that the secondary was opening a connection with the primary dns server.

The secondary is no longer responding to queries although it is running!  Using logging I can see each of the client requests being made to the secondary but I always get "connection timed out; no servers could be reached" or "DNS required timed out" on the client end.  I'm trying queries from localhost, a computer on the same network, so a firewall should not be an issue.

I'm going to have to open a new topic ( https://www.experts-exchange.com/questions/20798599/Redhat-7-2-DNS-server-times-out-client-requests-but-appears-to-be-running-fine.html ) and will come back to this topic to distribute points.

Could you see any outgoing packets destined for a primary server in a tcpdump on the local network? A lack of those might indicate a basic networking or configuration problem.

Yes I can see outgoing packets on the secondary via a tcpdump, so the networking configuration doesn't seem to be the issue.  I am running two NICs on the secondary DNS computer but just have the second NIC shut down for the time being.

It's weird that it won't resolve anything for me now at all, but is still logging requests that it receives and shows network traffic being sent/received...

Okay, does a tcpdump on a primary show the AXFR request  reaching the primary?

A tcpdump on the primary does not show the AXFR request.

The secondary tcpdump shows a SOA? request being sent to the primary.  Here is a small snippett:

19:28:37.018024 arthur.56301 > ns1.theyhost.com.domain:  6639 SOA? 08002.com. (27) (DF)
19:28:37.868000 arthur.56301 > ns1.theyhost.com.domain:  51900 SOA? RIRIC.COM. (27) (DF)

A simple telnet to ns1.theyhost.com 53 shows a response via tcpdump so I know that the secondary server ( ns1.vancetech.com ) can see the primary.

Check the serial number of the Zones on the primary. Numerically, they have to have a higher value than the serial number in the backup file on the secondary. If the SOA's match, or the numeric value on the secondary is higher, there won't be a transfer.

You could also try renaming one of the secondary backup files and restarting the named process to re-transfer the data.

Are you saying that when you did the tcpdumps on the primary and secondary that there was no evidence of any AXFR requests in either sniffer trace? If the secondary is initiating the request you ought to see the outgoing packet in a trace on the secondary.

What does 'netstat -nr' and 'ipconfig -a' on the secondary show?

The serial numbers on the primary DNS server match the serial numbers on the secondary.  I have increased the serial number on the primary to get the secondary to update them.  The secondary trys to refresh from the master but fails with the same error "refresh: failure trying master" for each zone.

Correct, there were no evidence of any AXFR requests in either server, the only requests are the SOA? packets from the secondary DNS server that don't get answered by the primary.

Here is my networking details:

netstat -nr

Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
192.168.0.0     0.0.0.0         255.255.255.0   U         0 0          0 eth1
127.0.0.0       0.0.0.0         255.0.0.0       U         0 0          0 lo
0.0.0.0         192.168.0.1     0.0.0.0         UG        0 0          0 eth1

ipconfig -a

eth0      Link encap:Ethernet  HWaddr 00:05:5D:FE:03:15  
          BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:4 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:0 (0.0 b)  TX bytes:240 (240.0 b)
          Interrupt:3 Base address:0xd800

eth1      Link encap:Ethernet  HWaddr 00:50:BA:40:64:23  
          inet addr:192.168.0.3  Bcast:192.168.0.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:17173278 errors:0 dropped:0 overruns:0 frame:0
          TX packets:14912414 errors:0 dropped:0 overruns:0 carrier:0
          collisions:578054 txqueuelen:100
          RX bytes:816120284 (778.3 Mb)  TX bytes:835477931 (796.7 Mb)
          Interrupt:4 Base address:0x4000

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:86480791 errors:0 dropped:0 overruns:0 frame:0
          TX packets:86480791 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:3576225844 (3410.5 Mb)  TX bytes:3576225844 (3410.5 Mb)