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