There are circumstances where it is necessary to translate an IP address back into the name of the device. This is especially useful in the traceroute application allowing the user to see the names of the machines through which packets are flowing instead of raw (and unrecognizable) IP addresses.
Reverse DNS resolution is performed the same way forward resolution is performed, except that the IP addresses and names are in opposite places. You can think of the computer storing everything in an upside-down tree-like structure with the top level domain at the top and the second and third level domains underneath it. For forward host name such as www.netscape.com, the .com is at the top, just under that is the .netscape part, and below that is the www part. Where the nameserver stores the www is also where it stores the IP address.
Reverse resolution is handled by placing it as a special branch off the root called .in-addr.arpa. This special branch allows for reverse resolution by placing names at the nodes corresponding with the IP address that is being resolved.
When looking up the IP address 192.234.42.5 the request is reformatted by the local resolver and sent to the nameserver as 5.42.234.192.in-addr.arpa. This looks like it's backwards, but if you look at the picture of the tree structure above, you can see that the name server stores the information in least-specific to most specific order. Resolution actually works better that way because the resolver begins with the least specific part of any name or address (.com in a name, and .in-addr.arpa in an IP address lookup) and works it's way to the most specific part (the www part of www.company.com in a name, and .5 of 192.234.42.5. What screws most people up is not knowing that IP addresses are actually backwards to start with. We're just putting them in the correct order when we do the lookup. ;-)
www . company-name . com
<== most specific least ==>
192 . 234 . 42 . 5
<== least specific most ==>
5 . 42 . 234 . 192 . in-addr . arpa
<== most specific least ==>
By the way, the 'in-addr' part simply means 'inverse address', and 'arpa' stands for ARPANET, which just goes to show you how old this process really is if you know what the ARPAnet is; and in 2000, the meaning was redesignated "Address and Routing Parameter Area" in RFC 3172. [1]
This 'backwards' way of representing things makes it possible for the programmers to be lazy and not have to write special logic or code to do reverse resolution. It's a strange workaround to the problem, but it works better because it uses the same steps as forward resolution would, and follows the same rules. This makes it's behavior predictable and logical because it doesn't differ greatly from forward lookups of domain names.
Confused? Well all you REALLY have to remember is that reverse resolution turns an IP address into a host name. The software takes care of the rest, and we humans can go on our merry way, blissfully unaware of all the ugly details. ;-)
[1] Thanks goes to Lixia Zhang @ UCLA for the updated RFC information.