What is reverse DNS?
Reverse DNS maps an IP address back to a hostname, the opposite of the usual name-to-address lookup. The answer comes from a PTR (pointer) record published under a special domain: in-addr.arpa for IPv4 and ip6.arpa for IPv6. This tool sends the address you enter to our server, which performs that lookup and returns the hostname, or tells you no PTR record exists.
Running a lookup
Enter one address and click Convert. Both families are accepted:
Input: 192.0.2.10
Output: web1.example.com
Input: 2001:db8::10
Output: web1-v6.example.com
(These are documentation addresses with made-up PTR names, to show the format. Real lookups return whatever the address holder has published.) Anything that isn't a valid IPv4 or IPv6 address, such as 300.1.1.1 or a hostname, returns Enter a valid IPv4 or IPv6 address.
Only one hostname is shown even if an address has several PTR records, since the underlying system call returns a single name.
How a PTR lookup is built
Reverse DNS reuses ordinary DNS by turning the address into a domain name. RFC 1035, section 3.5 defines the IPv4 scheme: write the four octets in reverse order and append in-addr.arpa. Reversing puts the most general part of the address on the right, matching how domain names are delegated.
| Address | Name queried for the PTR record |
|---|---|
192.0.2.10 |
10.2.0.192.in-addr.arpa |
2001:db8::10 |
0.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa |
IPv6 works the same way at a finer grain. RFC 3596 expands the address to all 32 hex digits and reverses them one nibble at a time under ip6.arpa, which is why the IPv6 name is so long. The PTR record type itself is part of the original DNS specification in RFC 1035, with the concepts laid out in RFC 1034.
Because the reverse zones are delegated along with the address blocks, the PTR for an address is controlled by whoever holds that block. That's the key to reading results correctly.
What results usually look like
| Kind of address | Typical PTR result |
|---|---|
| Major search engine crawler | A name under the operator's own domain |
| Cloud server with default settings | A provider-generated name that embeds the IP |
| Home or mobile broadband | An ISP name encoding the address and region, or nothing |
| Mail server set up properly | The server's own hostname, matching its forward DNS |
| Private ranges (10.x, 192.168.x, 172.16–31.x) | Usually nothing; these only resolve on their own network |
Verifying a crawler with reverse and forward DNS
A user-agent string is just text and anyone can claim to be Googlebot. Google's documented method for verifying Googlebot uses DNS in both directions:
- Take the requesting IP address from your server logs.
- Look it up here. A genuine crawler's name ends in
googlebot.com,google.comorgoogleusercontent.com. - Resolve that hostname forward with the hostname to IP tool.
- Check that the forward result includes the original IP. If it doesn't, the PTR record is lying and the visitor isn't Google.
Step 4 matters because a PTR record alone can say anything. This round-trip check is often called forward-confirmed reverse DNS. It's also why requests from tools like our spider simulator, which borrow Googlebot's user agent from a non-Google IP, fail verification on sites that check.
Other common uses
- Mail deliverability. Gmail's sender guidelines require a sending server's IP to have a PTR record whose hostname resolves back to that same IP. If your outbound mail is being rejected, look up your mail server's IP here, then check its DNS records.
- Reading logs. A raw IP in an access log becomes much more meaningful when the PTR names a known crawler, cloud provider or ISP.
- Network troubleshooting. Router hostnames in traceroute output often encode location codes that hint where traffic is going.
The answer comes from our server's resolver, so it reflects public DNS as seen from our network. For testing tools against made-up input rather than real hosts, the random IP generator produces sample addresses.
Last updated