Stops doing reverses for a few hours
Tuc
tuc at ttsg.com
Sat Oct 4 18:44:39 UTC 2003
Hi,
We have had a few servers that just seem to stop doing reverse
lookups for a few hours for all IPs in our netblock that aren't in cache.
hel# host -d -v 216.231.111.14
Forcing `-t a' for signature trace.
;; res_nmkquery(QUERY, 14.111.231.216.IN-ADDR.ARPA., IN, PTR)
;; res_send()
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11097
;; flags: rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; 14.111.231.216.IN-ADDR.ARPA, type = PTR, class = IN
;; Querying server (# 1) address = 216.231.105.163
;; new DG socket
;; timeout
;; Querying server (# 2) address = 216.231.111.14
;; new DG socket
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11097
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2
;; 14.111.231.216.IN-ADDR.ARPA, type = PTR, class = IN
14.111.231.216.IN-ADDR.ARPA. 1D IN PTR valhalla.ttsg.com.
111.231.216.IN-ADDR.ARPA. 1D IN NS valhalla.ttsg.com.
111.231.216.IN-ADDR.ARPA. 1D IN NS frigg.ttsg.com.
valhalla.ttsg.com. 1D IN A 216.231.111.14
frigg.ttsg.com. 1D IN A 209.51.161.86
rcode = 0 (Success), ancount=1
The following answer is not verified as authentic by the server:
14.111.231.216.IN-ADDR.ARPA 86400 IN PTR valhalla.ttsg.com
For authoritative answers, see:
111.231.216.IN-ADDR.ARPA 86400 IN NS valhalla.ttsg.com
111.231.216.IN-ADDR.ARPA 86400 IN NS frigg.ttsg.com
Additional information:
valhalla.ttsg.com 86400 IN A 216.231.111.14
frigg.ttsg.com 86400 IN A 209.51.161.86
But for a forward
hel# host -d -v tucs-beachin-obx-house.com
Forcing `-t a' for signature trace.
Trying null domain
;; res_nmkquery(QUERY, tucs-beachin-obx-house.com, IN, A)
;; res_send()
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27058
;; flags: rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; tucs-beachin-obx-house.com, type = A, class = IN
;; Querying server (# 1) address = 216.231.105.163
;; new DG socket
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27058
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0
;; tucs-beachin-obx-house.com, type = A, class = IN
tucs-beachin-obx-house.com. 2H IN A 204.107.90.2
tucs-beachin-obx-house.com. 2H IN NS ns15.zoneedit.com.
tucs-beachin-obx-house.com. 2H IN NS ns18.zoneedit.com.
rcode = 0 (Success), ancount=1
The following answer is not verified as authentic by the server:
tucs-beachin-obx-house.com 7200 IN A 204.107.90.2
For authoritative answers, see:
tucs-beachin-obx-house.com 7200 IN NS ns15.zoneedit.com
tucs-beachin-obx-house.com 7200 IN NS ns18.zoneedit.com
When I do an "ndc dumpdb" , the only reverse in my netblock is :
$ORIGIN 105.231.216.in-addr.arpa.
162 52012 IN PTR www.veloz.com. ;Cr=auth [209.51.161.86]
So if I do :
hel# host -d -v 216.231.105.162
Forcing `-t a' for signature trace.
;; res_nmkquery(QUERY, 162.105.231.216.IN-ADDR.ARPA., IN, PTR)
;; res_send()
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8237
;; flags: rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; 162.105.231.216.IN-ADDR.ARPA, type = PTR, class = IN
;; Querying server (# 1) address = 216.231.105.163
;; new DG socket
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8237
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 7, ADDITIONAL: 0
;; 162.105.231.216.IN-ADDR.ARPA, type = PTR, class = IN
162.105.231.216.IN-ADDR.ARPA. 13h59m23s IN PTR www.veloz.com.
216.IN-ADDR.ARPA. 23h11m30s IN NS chia.ARIN.NET.
216.IN-ADDR.ARPA. 23h11m30s IN NS dill.ARIN.NET.
216.IN-ADDR.ARPA. 23h11m30s IN NS henna.ARIN.NET.
216.IN-ADDR.ARPA. 23h11m30s IN NS indigo.ARIN.NET.
216.IN-ADDR.ARPA. 23h11m30s IN NS epazote.ARIN.NET.
216.IN-ADDR.ARPA. 23h11m30s IN NS figwort.ARIN.NET.
216.IN-ADDR.ARPA. 23h11m30s IN NS ginseng.ARIN.NET.
rcode = 0 (Success), ancount=1
The following answer is not authoritative:
The following answer is not verified as authentic by the server:
162.105.231.216.IN-ADDR.ARPA 50363 IN PTR www.veloz.com
For authoritative answers, see:
216.IN-ADDR.ARPA 83490 IN NS chia.ARIN.NET
216.IN-ADDR.ARPA 83490 IN NS dill.ARIN.NET
216.IN-ADDR.ARPA 83490 IN NS henna.ARIN.NET
216.IN-ADDR.ARPA 83490 IN NS indigo.ARIN.NET
216.IN-ADDR.ARPA 83490 IN NS epazote.ARIN.NET
216.IN-ADDR.ARPA 83490 IN NS figwort.ARIN.NET
216.IN-ADDR.ARPA 83490 IN NS ginseng.ARIN.NET
but then :
hel# host -d -v 216.231.105.163
Forcing `-t a' for signature trace.
;; res_nmkquery(QUERY, 163.105.231.216.IN-ADDR.ARPA., IN, PTR)
;; res_send()
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38148
;; flags: rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; 163.105.231.216.IN-ADDR.ARPA, type = PTR, class = IN
;; Querying server (# 1) address = 216.231.105.163
;; new DG socket
;; timeout
;; Querying server (# 2) address = 216.231.111.14
;; new DG socket
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38148
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2
;; 163.105.231.216.IN-ADDR.ARPA, type = PTR, class = IN
163.105.231.216.IN-ADDR.ARPA. 1D IN PTR hel.ttsg.com.
105.231.216.IN-ADDR.ARPA. 1D IN NS valhalla.ttsg.com.
105.231.216.IN-ADDR.ARPA. 1D IN NS frigg.ttsg.com.
valhalla.ttsg.com. 1D IN A 216.231.111.14
frigg.ttsg.com. 1D IN A 209.51.161.86
rcode = 0 (Success), ancount=1
The following answer is not verified as authentic by the server:
163.105.231.216.IN-ADDR.ARPA 86400 IN PTR hel.ttsg.com
For authoritative answers, see:
105.231.216.IN-ADDR.ARPA 86400 IN NS valhalla.ttsg.com
105.231.216.IN-ADDR.ARPA 86400 IN NS frigg.ttsg.com
Additional information:
valhalla.ttsg.com 86400 IN A 216.231.111.14
frigg.ttsg.com 86400 IN A 209.51.161.86
What could be causing this?
Thanks, Tuc/TTSG Internet Services, Inc.
More information about the bind-users
mailing list