Solved

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

Posted on 2003-11-11
19
864 Views
Last Modified: 2012-08-13
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 xxxxxxxxxxxxxx.com/IN: refresh: failure trying master xx.xx.xx.xx#53: timed out
Nov 11 20:46:25 arthur named[31129]: zone xxxxxxxxxxxxxx.com/IN: refresh: retry limit for master xx.xx.xx.xx#53 exceeded

Any ideas? Thank you.
0
Comment
Question by:vancetech
  • 8
  • 6
  • 4
  • +1
19 Comments
 
LVL 40

Expert Comment

by:jlevie
ID: 9731267
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?
0
 
LVL 26

Expert Comment

by:jar3817
ID: 9733401
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.
0
 

Author Comment

by:vancetech
ID: 9733624
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.
0
 
LVL 40

Expert Comment

by:jlevie
ID: 9734033
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.
0
 
LVL 12

Expert Comment

by:mburdick
ID: 9736328
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.
0
 
LVL 40

Expert Comment

by:jlevie
ID: 9736368
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.
0
 
LVL 12

Expert Comment

by:mburdick
ID: 9736412
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.
0
 

Author Comment

by:vancetech
ID: 9736456
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.
0
 
LVL 12

Expert Comment

by:mburdick
ID: 9736497
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?
0
Control application downtime with dependency maps

Visualize the interdependencies between application components better with Applications Manager's automated application discovery and dependency mapping feature. Resolve performance issues faster by quickly isolating problematic components.

 
LVL 40

Expert Comment

by:jlevie
ID: 9737553
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.
0
 

Author Comment

by:vancetech
ID: 9751275
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 ( http://www.experts-exchange.com/Networking/Linux_Networking/Q_20798599.html ) and will come back to this topic to distribute points.
0
 
LVL 40

Expert Comment

by:jlevie
ID: 9751439
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.
0
 

Author Comment

by:vancetech
ID: 9751863
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...
0
 
LVL 40

Expert Comment

by:jlevie
ID: 9752267
Okay, does a tcpdump on a primary show the AXFR request  reaching the primary?
0
 

Author Comment

by:vancetech
ID: 9793453
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.
0
 
LVL 12

Expert Comment

by:mburdick
ID: 9796449
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.
0
 
LVL 40

Expert Comment

by:jlevie
ID: 9798295
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?
0
 

Author Comment

by:vancetech
ID: 9800548
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)
0
 
LVL 40

Accepted Solution

by:
jlevie earned 125 total points
ID: 9801643
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.
0

Featured Post

Find Ransomware Secrets With All-Source Analysis

Ransomware has become a major concern for organizations; its prevalence has grown due to past successes achieved by threat actors. While each ransomware variant is different, we’ve seen some common tactics and trends used among the authors of the malware.

Join & Write a Comment

I have seen several blogs and forum entries elsewhere state that because NTFS volumes do not support linux ownership or permissions, they cannot be used for anonymous ftp upload through the vsftpd program.   IT can be done and here's how to get i…
Note: for this to work properly you need to use a Cross-Over network cable. 1. Connect both servers S1 and S2 on the second network slots respectively. Note that you can use the 1st slots but usually these would be occupied by the Service Provide…
This video discusses moving either the default database or any database to a new volume.
This video shows how to remove a single email address from the Outlook 2010 Auto Suggestion memory. NOTE: For Outlook 2016 and 2013 perform the exact same steps. Open a new email: Click the New email button in Outlook. Start typing the address: …

760 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

21 Experts available now in Live!

Get 1:1 Help Now