On 2014-10-10 23:28, lleachii@aol.com wrote: [..]
The only pattern that I've discovered when a lookup times out, is that the fourth octet is always less than 10. I've checked the system log, and there is no denial for the DSN query. I was wondering if anyone had ideas/suggestions.
Try something like:
$ dig @8.8.8.8 2.1.102.44.in-addr.arpa. ptr
Where 8.8.8.8 is not google public dns, but your own recursor.
You can also force a trace which should show where the thinking qoes wrong:
$ dig @8.8.8.8 +trace 2.1.102.44.in-addr.arpa. ptr
[...]
2.1.102.44.in-addr.arpa. 3600 IN PTR hamgate2.washtenaw.ampr.org. 44.in-addr.arpa. 3600 IN NS ampr-dns.in-berlin.de. 44.in-addr.arpa. 3600 IN NS ns1.defaultroute.net. 44.in-addr.arpa. 3600 IN NS ampr.org. 44.in-addr.arpa. 3600 IN NS hamradio.ucsd.edu. 44.in-addr.arpa. 3600 IN NS ns0.comgw.net. 44.in-addr.arpa. 3600 IN NS ns2.threshinc.com. 44.in-addr.arpa. 3600 IN NS munnari.OZ.AU. ;; Received 366 bytes from 202.29.151.3#53(202.29.151.3) in 437 ms
Seems that the 44-reverse boxes all have it in their own zone directly.
Hence, what you should verify is if the host that is your recursor can reach all the NSs listed above. You can check that with:
$ for i in `dig +short 44.in-addr.arpa. ns`; do echo $i; time dig +short @$i 2.1.102.44.in-addr.arpa. ptr; done munnari.OZ.AU. hamgate2.washtenaw.ampr.org.
real 0m0.366s user 0m0.005s sys 0m0.005s ampr.org. hamgate2.washtenaw.ampr.org.
real 0m0.308s user 0m0.006s sys 0m0.007s ampr-dns.in-berlin.de. hamgate2.washtenaw.ampr.org.
real 0m0.046s user 0m0.006s sys 0m0.006s ns1.defaultroute.net. hamgate2.washtenaw.ampr.org.
real 0m0.117s user 0m0.004s sys 0m0.004s hamradio.ucsd.edu. hamgate2.washtenaw.ampr.org.
real 0m0.247s user 0m0.006s sys 0m0.006s ns0.comgw.net. hamgate2.washtenaw.ampr.org.
real 0m0.043s user 0m0.005s sys 0m0.005s ns2.threshinc.com. hamgate2.washtenaw.ampr.org.
real 0m0.188s user 0m0.004s sys 0m0.004s
Another good check is if they have IPv4 + IPv6:
$ for i in `dig +short 44.in-addr.arpa. ns`; do echo $i; dig +short $i a; done munnari.OZ.AU. 202.29.151.3 ampr.org. 44.0.0.1 ampr-dns.in-berlin.de. 192.109.42.4 ns1.defaultroute.net. 74.120.14.69 hamradio.ucsd.edu. 169.228.66.6 ns0.comgw.net. 195.66.148.101 ns2.threshinc.com. 192.41.222.8
$ for i in `dig +short 44.in-addr.arpa. ns`; do echo $i; dig +short $i aaaa; done munnari.OZ.AU. 2001:3c8:9007:1::21 2001:3c8:9009:181::2 ampr.org. ampr-dns.in-berlin.de. 2a01:238:4073:e600::1 ns1.defaultroute.net. hamradio.ucsd.edu. ns0.comgw.net. ns2.threshinc.com. 2604:5000:0:2::2
Which seems to be the case for some of them. Hence check if your connectivity is affected by that, eg you having a broken IPv6 default route for instance.
As you are using BIND, do check the logs as BIND typically complains quite well about issues with unreachable remote servers.
I also recall there was another person recently here on 44net who complained about similar issues with slow responses.
Greets, Jeroen