How to find authoritative server for reverse lookup

[Kevin Darcy]

TAT LUK wrote:

>         Can someone tell me how to find the authoritative server for reverse
> lookup of an    address or a block of address? What would that command be in
> nslookup under NT,
>         say if I want to find the reverse lookup authoritative server of
> address block
>         208.215.237.0-255 or an address like 208.215.237.1? Thanks.

No offense intended, but do you understand the concept of delegation? The set
of nameservers which controls a chunk of reverse-address space at the /24 level
may however delegate individual addresses as zones to some other (possibly
overlapping) set of nameservers. Or, following RFC 2317, they may have alias
entries in the /24 zone pointing to PTRs in some totally different zone, thus
effectively "delegating" the content of those reverse lookups to some other set
of nameservers.

So, if you just want to know what the authoritative nameservers are for the
reverse zone corresponding to the 208.215.237/24 address block, then do a type
"NS" lookup of 237.215.208.in-addr.arpa (note that for the reverse-address
namespace, you just take the octets, reverse them, and append "in.addr.arpa").

Then, if you want to see what's *in* that zone, including any aliases or
subzone delegations, and if one or more of the nameservers for the zone is kind
enough to let you do zone transfers, then switch server to one of those
nameservers and do a zone transfer ("ls -d" in nslookup). When I do that on the
Internet version of 237.215.208.in-addr.arpa, I see that the zone is
effectively empty (just a SOA record and NS records). But if there were aliases
and/or subzone delegations in there, I'd follow up by doing a PTR lookup on
each of them, directed at a recursive server, with "debug" enabled, and then
noting the Authority Sections of the responses.

If the authoritative servers for 237.215.208.in-addr.arpa aren't kind enough to
allow zone transfers (for all I know, maybe you want to interrogate an
*internal* 208.215.237/24 address range), then your only real alternative is to
issue a query for each address in the range. Again, turning on "debug" will
inform you whether there's any aliasing or subzone delegation occurring, and
the Authority Section contents should always tell you the zone which actually
contains the PTR records themselves.


- Kevin