reverse DNS
Normal DNS goes name to address: you have www.example.com, you want the number. Reverse DNS goes the other way: you have a number like 93.184.216.34, and you want to know what name claims it. It is like having a phone number and wanting to find whose it is — a reverse directory. This backward lookup answers the question who is this address, according to DNS?
The clever part is how it reuses the same tree. You cannot literally search all of DNS for an address, so reverse DNS turns the address into a special name and looks that up normally. For IPv4, the address octets are reversed and placed under a dedicated zone: 93.184.216.34 becomes the name 34.216.184.93.in-addr.arpa, and a PTR (pointer) record stored there gives back a domain name. IPv6 uses a similar scheme under ip6.arpa. Crucially, reverse DNS is controlled by whoever was delegated that block of addresses — usually the network operator that owns the IP range, not the website owner — so forward and reverse can disagree.
Why it matters: reverse DNS is widely used as a sanity check rather than proof. Mail servers, for instance, often look up the reverse name of a connecting IP and are suspicious if it is missing or does not match, because legitimate mail senders usually have proper reverse records — it is a weak anti-spam signal. The honest caveat: a matching PTR proves only that the address's network operator set that name; it does not authenticate identity, and a name in a PTR record can say anything its operator chose.
To find the name for 8.8.8.8, a reverse lookup queries the PTR record at 8.8.8.8.in-addr.arpa, which returns dns.google. The address octets were flipped and parked under in-addr.arpa so the ordinary downward DNS walk could resolve them.
Flip the address into a name under in-addr.arpa, then look up its PTR.
A PTR record is not authoritative proof of identity. The address block's operator controls reverse DNS, so a PTR can say anything they set, and forward (A) and reverse (PTR) records need not agree.