axfr fails, telnet to 53 works

jeff donovan jdonovan at beth.k12.pa.us
Fri Jun 10 03:18:07 UTC 2005


On Jun 9, 2005, at 10:46 PM, /dev/rob0 wrote:

> Sorry, this might be a routing or firewall issue, but I'm hoping  
> perhaps
> someone here can help anyway. I maintain my own internal DNS over a
> network of VPN links. The master server died recently and I  
> replaced it
> with a machine on another IP.
Note*
> But I did bind the old IP, 192.168.6.1, to
> the new master.
>
> The client at 10.27.1.3 can't do a zone transfer. All the following
> commands are on that machine. It can route there through the VPN:
>
> $ traceroute 192.168.6.1
> traceroute to 192.168.6.1 (192.168.8.101), 30 hops max, 38 byte  
> packets
>   1  fw (10.27.1.1)  0.179 ms  0.083 ms  0.068 ms
>   2  192.168.6.1 (192.168.6.1)  35.087 ms  40.455 ms  38.363 ms
>
> It can ping and get replies:

okay
>
> $ ping -c2 192.168.6.1
> PING 192.168.6.1 (192.168.6.1): 56 octets data
> 64 octets from 192.168.6.1: icmp_seq=0 ttl=63 time=52.0 ms
> 64 octets from 192.168.6.1: icmp_seq=1 ttl=63 time=34.4 ms
>
> --- 192.168.6.1 ping statistics ---
> 2 packets transmitted, 2 packets received, 0% packet loss
> round-trip min/avg/max = 34.4/43.2/52.0 ms
>
> Individual queries, both UDP and TCP, work:
>
> $ host 192.168.6.1 192.168.6.1
> Using domain server:
> Name: 192.168.6.1
> Address: 192.168.6.1#53
> Aliases:
>
> 1.6.168.192.in-addr.arpa domain name pointer master.lan.
> $ host -T 192.168.6.1 192.168.6.1
> Using domain server:
> Name: 192.168.6.1
> Address: 192.168.6.1#53
> Aliases:
>
> 1.6.168.192.in-addr.arpa domain name pointer master.lan.
>
> But here's axfr:
>
> $ dig @192.168.6.1 master.lan. axfr
>
> ; <<>> DiG 9.2.1 <<>> @192.168.6.1 master.lan. axfr
> ;; global options:  printcmd
> ;; connection timed out; no servers could be reached

ps -aux | grep namedb


>
> This is logged on the server:
>
> Jun  9 20:50:25 whn named[1376]: client 10.27.1.3#33948: transfer of
> 'master.lan/IN': AXFR started

check log severity level in named.conf

     channel _default_log    {
         file "/var/log/named.log";
         severity debug;
         print-time yes;
     );

reboot named

then tail -f named.log
watch for zone errors. they won't lie to you :)

could have an ip mismatch with zone master file See Note* dns server  
hostname foobar.

>
> 10.27.0.0/16 is in an ACL which is included in an allow-transfer
> directive for the master.lan. zone on the server.

remove all access lists during initial test. permit all temporarily,  
unless you run an insecure box, then verification of that list needs  
to be verified some other way.
>
>
> The OS is Slackware Linux, a hybrid of 9.1 through 10.1, and the BIND
> version on the server is a bit old, 9.2.3. I'll try upgrading that and
> will report back on whether it worked. The client is older, Slackware
> 8.1 and BIND 9.2.1, as you can see above. Could that be the problem?
bind worked in 8 and it works in 9
>
> The main IP on the interface was assigned by a stupid router (the  
> server
> that died had also been my DHCP server and Internet gateway.) The main
> IP is 192.168.0.102 with a /16 netmask.
does your dns server need to go through this device to speak to your  
clients? probably yes.

if your dns box is located at 192.168.6.1 thats a /24 class C. your  
router and dhcp server are on the dot zero network ( 192.168.0.0)  
different class C. So to hop between subnets the your router must be  
queried. even if you have your mask set for 255.255.0.0, that will  
broaden your broadcast range, but your actual requests will need to  
consult the router.
so your router setting could be an issue. but if you can ping the  
box, your usually okay. ping the port instead, from both ends. i  
suspect your named process failed to load.

my.02


>
>
> Any ideas about how to troubleshoot this will be appreciated. Oh,  
> and of
> course it used to work on the old server, which had the same BIND  
> version.
>

another day.

-j



More information about the bind-users mailing list