 |  |
Nope.
Re: OS X vs Reverse Lookups
From: Men & Mice Support
Date: Monday, July 22, 2002
Time: 9:53:46 am
The error message you got back from nslookup is your first clue:
Server failed. That indicates that your local server received a
SERVFAIL response from a server that's supposed to be authoritative
for the class C subnet reverse zone.
Here's what I see when I try to look up the PTR record in question
(starting with the +trace in dig version 9):
____________________________________________________________________
> dig +trace +norecurse -x 209.31.26.68 PTR
; <<>> DiG 9.2.1 <<>> +trace +norecurse -x 209.31.26.68 PTR
;; global options: printcmd
. 102234 IN NS E.ROOT-SERVERS.NET.
. 102234 IN NS F.ROOT-SERVERS.NET.
. 102234 IN NS G.ROOT-SERVERS.NET.
. 102234 IN NS H.ROOT-SERVERS.NET.
. 102234 IN NS I.ROOT-SERVERS.NET.
. 102234 IN NS J.ROOT-SERVERS.NET.
. 102234 IN NS K.ROOT-SERVERS.NET.
. 102234 IN NS L.ROOT-SERVERS.NET.
. 102234 IN NS M.ROOT-SERVERS.NET.
. 102234 IN NS A.ROOT-SERVERS.NET.
. 102234 IN NS B.ROOT-SERVERS.NET.
. 102234 IN NS C.ROOT-SERVERS.NET.
. 102234 IN NS D.ROOT-SERVERS.NET.
;; Received 292 bytes from 192.168.1.1#53(192.168.1.1) in 9 ms
209.in-addr.arpa. 86400 IN NS ARROWROOT.ARIN.NET.
209.in-addr.arpa. 86400 IN NS BUCHU.ARIN.NET.
209.in-addr.arpa. 86400 IN NS CHIA.ARIN.NET.
209.in-addr.arpa. 86400 IN NS DILL.ARIN.NET.
209.in-addr.arpa. 86400 IN NS EPAZOTE.ARIN.NET.
209.in-addr.arpa. 86400 IN NS FIGWORT.ARIN.NET.
209.in-addr.arpa. 86400 IN NS GINSENG.ARIN.NET.
209.in-addr.arpa. 86400 IN NS HENNA.ARIN.NET.
209.in-addr.arpa. 86400 IN NS INDIGO.ARIN.NET.
;; Received 240 bytes from 192.203.230.10#53(E.ROOT-SERVERS.NET) in 41 ms
31.209.in-addr.arpa. 86400 IN NS NAMESERVER2.CONCENTRIC.NET.
31.209.in-addr.arpa. 86400 IN NS NAMESERVER3.CONCENTRIC.NET.
31.209.in-addr.arpa. 86400 IN NS NAMESERVER.CONCENTRIC.NET.
31.209.in-addr.arpa. 86400 IN NS NAMESERVER1.CONCENTRIC.NET.
;; Received 160 bytes from 198.133.199.110#53(ARROWROOT.ARIN.NET) in 233 ms
68.26.31.209.in-addr.arpa. 28800 IN CNAME
68.64/27.26.31.209.in-addr.arpa.
;; Received 66 bytes from
207.155.184.72#53(NAMESERVER2.CONCENTRIC.NET) in 117 ms
____________________________________________________________________
So, what just happened? The 'dig' command first queried my local
nameserver looking for root servers. It then queried a root server
the first delegation, and followed the resulting chain of delegations
to concentric.net. Concentric gave a CNAME record, and that's the
last meaningful answer 'dig' received.
So, I followed this up a bit. I queried ns2.concentric.net for
records relating to 64/27.26.31.209.in-addr.arpa, and it returned a
SERVFAIL result.
____________________________________________________________________
> dig +norecurse any 64/27.26.31.209.in-addr.arpa @NAMESERVER2.CONCENTRIC.NET
; <<>> DiG 9.2.1 <<>> +norecurse any 64/27.26.31.209.in-addr.arpa
@NAMESERVER2.CONCENTRIC.NET
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 28390
;; flags: qr ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;64/27.26.31.209.in-addr.arpa. IN ANY
;; Query time: 163 msec
;; SERVER: 207.155.184.72#53(NAMESERVER2.CONCENTRIC.NET)
;; WHEN: Mon Jul 22 09:43:48 2002
;; MSG SIZE rcvd: 46
____________________________________________________________________
The other three Concentric servers gave the same response. So the net
result is, the delegation is broken at Concentric.
____________________________________________________________________
Chris Buxton Men & Mice
support@menandmice.com Making DNS Easy
At 3:41 PM -0700 7/21/02, Bill Staudenheimer wrote:
>QuickDNS Manager for OS X 3.5
>
>Recently upgraded to OS X 10.1.5
>:
>Suddenly, the Reverse Address lookup requests for
> 64-27.26.31.209.in-addr.arpa
>cannot find the server, although the configuration has been in use since
>March.
>Forward lookups resolve just fine.
>
>
>REVERSE:
>> set type=PTR
> > 209.31.26.68
>Server: [209.31.26.68]
>Address: 209.31.26.68
>
>*** [209.31.26.68] can't find 68.26.31.209.in-addr.arpa.: Server failed
>
>FORWARD
>> set type=A
>> ns.staudenheimer.com
>Server: [209.31.26.68]
>Address: 209.31.26.68
>
>
>The same setup, running on an OS 9 with QuickDNS Pro,
>works correctly in both directions, so I believe the delegation
>from the ISP is still correct.
>
>Both named and qdns are running.
>
>My impression is that something changed in 10.1.5.
>Any clues about what to look for?
>
>Bill
>System Guides
>bstaud@sysgu.com
Messages In This Thread:
Return to Digital Point Solutions' Home Page