10 Oct
2014
10 Oct
'14
5:28 p.m.
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
11 Oct
11 Oct
2:07 a.m.
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(a)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.
7:51 a.m.
On 2014-10-10 23:28, lleachii(a)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
3695
days inactive
3696
days old
2 comments
3 participants
participants (3)
-
Brian Kantor -
Jeroen Massar -
lleachii＠aol.com