If you have nslookup
available, and the IP
you want to resolve is aa.bb.cc.dd, you can simply type:
# nslookup -type=PTR dd.cc.bb.aa.in-addr.arpa
(actually, modern implementations of nslookup
will do this translation
for you, allowing you to just type nslookup aa.bb.cc.dd
, but this is less instructive.)
As you might guess from the above, reverse DNS lookup is basically a kludge, ... er, wonderful and forward-thinking piece of design. It works through hierarchical control over the magical in-addr.arpa domain, which is configured in much the same way as a normal .com in the DNS.
For instance, if I want to have my DNS resolve addresses in the 192.168.0.0/16 private address space, I simply tell my copy of bind in named.conf that it is a master for the domain 168.192.in-addr.arpa. I can then put PTR records such as
18.104.22.168.in-addr.arpa. IN PTR mybox.intranet.
1.4 IN PTR gateway.intranet.
4.1 IN PTR dns.intranet.
into the zonefile
, causing 192.168.1.1 to resolve as mybox
, 192.168.4.1 to resolve as gateway
and 192.168.1.4 to resolve as dns
Subdomains sub-subdomains and sub-sub-subdomains of in-addr.arpa (corresponding to class A, class B and class C sized blocks, respectively) are allocated by the IP registries -- RIPE in Europe, for example -- to network operators who are responsible for blocks of IP addresses.
Technically, this happens in much the same way that subdomains of .com are allocated to domain owners - through simple NS records in the master DNS.
A good way to see which network operator is locally responsible for an IP address (because, guess what? they don't always resolve!) is often to resolve the relevant NS records, indicating who runs the name servers for that IP block:
nslookup -type=NS 130.182.195.in-addr.arpa
for example. (Though of course the canonical way to do this is via a whois
query on the block at the relevant registry.
whois -h whois.ripe.net 195.182.130
would be the corresponding query.)
I remember once watching a large part of the European end of this fall apart, when some staffer at internic, noticed that RIPE had never actually paid to run the domain ripe.net (which is in the NS records for domains like 195.in-addr.arpa, as well as providing top-level routing information) and purged them from the .net zonefile, to the giddy amusement of all...