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

I just got a D-Link DI-604 broadband firewall/router for my room, which has a secondary DNS server that I run on a Redhat Linux 7.2 box.  The problem is that now the secondary server is unable to retreive updates from the primary server located elsewhere on the internet.  The primary server is running a Redhat Linux 7.2 box with an Ipchains firewall.  Has anyone have experience with the DLINK router and this type of DNS problem yet?

Here is a snippet of the logfiles.  I'm guessing that UDP packets are being denied over the 2 firewalls.  

Nov 11 20:46:25 arthur named[31129]: zone refresh: failure trying master xx.xx.xx.xx#53: timed out
Nov 11 20:46:25 arthur named[31129]: zone refresh: retry limit for master xx.xx.xx.xx#53 exceeded

Any ideas? Thank you.
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

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 -p tcp -m tcp --dport 53 -j ACCEPT

just make sure you substitute the for the ip of the primary nameserver.
vancetechAuthor Commented:
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 ( ).   ( DLINK FIREWALL = Allow Virtual Server DNS WAN,* LAN, 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.
Introduction to R

R is considered the predominant language for data scientist and statisticians. Learn how to use R for your own data science projects.

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.
MarkLead Sales Engineer - Public SectorCommented:
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.
MarkLead Sales Engineer - Public SectorCommented:
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.
vancetechAuthor Commented:
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.
MarkLead Sales Engineer - Public SectorCommented:
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.
vancetechAuthor Commented:
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 ( ) 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.
vancetechAuthor Commented:
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?
vancetechAuthor Commented:
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 >  6639 SOA? (27) (DF)
19:28:37.868000 arthur.56301 >  51900 SOA? RIRIC.COM. (27) (DF)

A simple telnet to 53 shows a response via tcpdump so I know that the secondary server ( ) can see the primary.
MarkLead Sales Engineer - Public SectorCommented:
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?
vancetechAuthor Commented:
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   U         0 0          0 eth1       U         0 0          0 lo         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:  Bcast:  Mask:
          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:  Mask:
          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)
Your network configuration certainly looks sane, not that really expected it to be otherwise. I suspect that the lack of a response to the SOA query is probably significant. Could you run a sniff on a primary and on the secondary at the same time and see if the SOA query you see leaving the secondary ever makes it to the primary? If that query never gets there something with the DLINK could be to blame. Could your DLINK have gotten a different outside IP? It certainly would have a different MAC and if your provider uses DHCP that would cause a different outside IP to be assigned.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Linux Networking

From novice to tech pro — start learning today.