All,
I'm wondering if anyone else has seen this issue. I'm running BIND version 9.9.5 at 44.60.44.3. I just recently upgraded from 9.8 because I thought it would solve a very weird issue that I'm experiencing.
I allow all to to lookup 44.in-addr.arpa and ampr.org; and it works. BUT, some reverse records always time out.
So far, I have tested the following IP addresses which have PTR records, but do not produce results:
44.102.1.1 44.102.1.2
44.108.1.1 44.108.1.2 44.108.1.3
44.60.44.1 44.60.44.2 44.60.44.3 44.60.44.6 44.60.44.7
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.
Thanks and 73,
Lynwood KB3VWG
Lynwood, I tried looking up the PTR record for some of those addresses, and all of them respond to me quickly - just milliseconds. I don't know what tool you're using, but "dig +trace" can be helpful in determining the lookup hierarchy that was followed and may point to where the lookups that you're doing have failed.
Here is "dig +trace -x 44.60.44.1" from my home. Note that it returned the answer in 41 ms, no timeout. I tried it a few times and always got an answer quickly; the longest (240 ms) was when the last server to be queried was Munnari across the Pacific Ocean. - Brian
; <<>> DiG 9.7.1-P2 <<>> +trace -x 44.60.44.1 ;; global options: +cmd . 474646 IN NS c.root-servers.net. . 474646 IN NS l.root-servers.net. . 474646 IN NS d.root-servers.net. . 474646 IN NS i.root-servers.net. . 474646 IN NS e.root-servers.net. . 474646 IN NS m.root-servers.net. . 474646 IN NS b.root-servers.net. . 474646 IN NS a.root-servers.net. . 474646 IN NS j.root-servers.net. . 474646 IN NS g.root-servers.net. . 474646 IN NS f.root-servers.net. . 474646 IN NS h.root-servers.net. . 474646 IN NS k.root-servers.net. ;; Received 228 bytes from 209.18.47.61#53(209.18.47.61) in 14 ms
in-addr.arpa. 172800 IN NS e.in-addr-servers.arpa. in-addr.arpa. 172800 IN NS c.in-addr-servers.arpa. in-addr.arpa. 172800 IN NS d.in-addr-servers.arpa. in-addr.arpa. 172800 IN NS f.in-addr-servers.arpa. in-addr.arpa. 172800 IN NS a.in-addr-servers.arpa. in-addr.arpa. 172800 IN NS b.in-addr-servers.arpa. ;; Received 417 bytes from 192.5.5.241#53(f.root-servers.net) in 24 ms
44.in-addr.arpa. 86400 IN NS munnari.oz.au. 44.in-addr.arpa. 86400 IN NS ampr-dns.in-berlin.de. 44.in-addr.arpa. 86400 IN NS ampr.org. 44.in-addr.arpa. 86400 IN NS hamradio.ucsd.edu. 44.in-addr.arpa. 86400 IN NS ns2.threshinc.com. 44.in-addr.arpa. 86400 IN NS ns0.comgw.net. 44.in-addr.arpa. 86400 IN NS ns1.defaultroute.net. ;; Received 245 bytes from 193.0.9.1#53(f.in-addr-servers.arpa) in 149 ms
1.44.60.44.in-addr.arpa. 3600 IN PTR kb3vwg-001.ampr.org. 44.in-addr.arpa. 3600 IN NS ampr-dns.in-berlin.de. 44.in-addr.arpa. 3600 IN NS ns2.threshinc.com. 44.in-addr.arpa. 3600 IN NS munnari.OZ.AU. 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 ns1.defaultroute.net. ;; Received 330 bytes from 192.41.222.8#53(ns2.threshinc.com) in 41 ms
On Fri, Oct 10, 2014 at 05:28:22PM -0400, lleachii@aol.com wrote:
I allow all to to lookup 44.in-addr.arpa and ampr.org; and it works. BUT, some reverse records always time out. So far, I have tested the following IP addresses which have PTR records, but do not produce results:
44.102.1.1 44.102.1.2
44.108.1.1 44.108.1.2 44.108.1.3
44.60.44.1 44.60.44.2 44.60.44.3 44.60.44.6 44.60.44.7
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.
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
-
Brian Kantor -
Jeroen Massar -
lleachii＠aol.com