Reverse DNS lookup: how bot verification actually works
On this page
A reverse DNS lookup takes an IP address and returns the hostname registered to it. It is the mirror image of the everyday DNS lookup that turns a domain like example.com into an IP address. Reverse DNS is old plumbing, but it quietly does one job that matters more every month: it is the first step in proving that a bot hitting your server is the crawler it claims to be, and not something wearing a fake user agent.
Most articles about reverse DNS stop at the networking definition or hand you a lookup tool. This one goes further, because a raw reverse lookup on its own proves almost nothing about a bot. The technique that actually verifies a crawler is forward-confirmed reverse DNS, and it is the exact method Google and Bing publish for their own crawlers. Here is how the whole chain works, where it fails, and what you pair it with when a crawler does not support it.
What a reverse DNS lookup is
A reverse DNS lookup resolves an IP address back to a domain name using a PTR record. A PTR (“pointer”) record is a DNS entry that lives under a special reserved zone and points an IP address at a hostname. It is the opposite of an A record, which points a hostname at an IP address.
The reverse lookup does not query the IP directly. Instead it reverses the octets of the address and appends in-addr.arpa for IPv4 (or ip6.arpa for IPv6), then asks for the PTR record at that name. So a lookup on 66.249.66.1 actually queries 1.66.249.66.in-addr.arpa. Whoever controls the IP block controls those PTR records, which is the detail that makes reverse DNS useful for verification: only the real operator of an address range can set the hostname it points to.
You can run one from any terminal:
dig -x 66.249.66.1 +short
# crawl-66-249-66-1.googlebot.com.That single answer tells you the operator of the IP claims the name googlebot.com. It does not yet prove the request came from Google. To understand why, you have to see how easily the reverse half can be gamed.
Why plain reverse DNS is not enough
A reverse DNS lookup alone cannot verify a bot because the PTR record and the source IP are controlled by different parties, and an attacker only needs to fake the part you check. Bot traffic is trivial to disguise. Any script can set its User-Agent header to Googlebot/2.1 or GPTBot, and plenty of scrapers do exactly that to slip past rules meant for humans. The user agent string is self-reported text with no cryptographic backing, so it is worthless as proof. If you want to see how much of this is hitting your own site, reading it out of your server logs is the fastest reality check.
Reverse DNS looks stronger because the PTR record has to be configured by whoever owns the IP block. But there is a catch. Someone operating their own IP range can point its PTR records at any hostname they like, including crawl-x-y-z.googlebot.com. If you stop after the reverse lookup and see a googlebot.com suffix, you can be fooled by an operator who simply lied in their own reverse zone. The PTR record proves who controls the IP’s reverse zone, not who controls the domain it names.
The fix is to make the two halves confirm each other, so a forged PTR record cannot stand on its own.
Forward-confirmed reverse DNS (FCrDNS)
Forward-confirmed reverse DNS verifies an IP by checking that its reverse lookup and a matching forward lookup agree. You take the IP, resolve it to a hostname with a PTR record, then resolve that hostname back to an IP with a normal A or AAAA lookup, and confirm you land on the same IP you started with. If the round trip closes, the record is authentic. If it does not, the claim is fake.
FCrDNS works because the two records are controlled by different owners who both have to cooperate. The PTR record is set by the IP block operator. The forward A record for crawl-66-249-66-1.googlebot.com is set by whoever controls the googlebot.com zone, which is Google. An attacker can forge a PTR record pointing at googlebot.com, but they cannot make Google’s authoritative DNS return the attacker’s IP for that hostname. The forward confirmation is the step they cannot forge.
This is not a Lume invention or an obscure trick. It is the verification method Google documents for confirming Googlebot, and Bing publishes the same technique for Bingbot against the search.msn.com domain. When the search engines themselves tell you how to check their crawlers, FCrDNS is the answer they give.
A concrete FCrDNS check against a Googlebot IP
Run FCrDNS by hand in three commands. Start with an IP that shows up in your logs claiming to be Googlebot, then close the loop.
Step one, reverse the IP to a hostname:
dig -x 66.249.66.1 +short
# crawl-66-249-66-1.googlebot.com.Step two, check the hostname ends in a domain Google actually owns. Google uses googlebot.com and google.com (and googleusercontent.com for some fetchers). A suffix of googlebot.com passes this gate. A suffix like googlebot.com.attacker.net does not, so match the end of the string precisely, not a substring anywhere in it.
Step three, resolve that hostname forward and confirm it returns your original IP:
dig crawl-66-249-66-1.googlebot.com +short
# 66.249.66.1The IP you started with (66.249.66.1) matches the IP the forward lookup returned. All three conditions hold: the PTR resolves, the hostname belongs to Google, and the forward lookup round-trips. This request is genuinely from Googlebot. If step three had returned a different IP, or step two had shown a non-Google domain, you would treat the traffic as a spoof no matter what the user agent said.
The same pattern verifies Bingbot, with the hostname ending in search.msn.com instead. The logic never changes: reverse, match the domain, forward-confirm.
Where reverse DNS runs out
FCrDNS is strong but not universal, because it only works for operators who publish PTR records and run authoritative forward DNS for a domain they own. A growing share of automated traffic does neither.
Many AI crawlers skip reverse DNS entirely and publish IP ranges instead. Rather than maintaining PTR records for every address, operators post a machine-readable list of the CIDR blocks their crawler uses, and you verify a request by checking whether its source IP falls inside a published range. Google itself offers this as an alternative to FCrDNS, publishing googlebot.json with its ranges. OpenAI’s GPTBot documents its IP blocks this way, and other AI operators follow the same pattern. Published-IP checks are faster than a DNS round trip because there is no live lookup, but they carry a cost: the list is only as fresh as the operator keeps it, and you have to fetch and cache it before every check.
There is a newer answer that fixes the trust problem at the request level rather than the network level. Web Bot Auth has crawlers sign each request with a cryptographic key, so the bot proves its identity in an HTTP header that cannot be replayed or spoofed, independent of which IP it came from. If you want the mechanics, our explainer on Web Bot Auth walks through the signature scheme, and the Web Bot Auth overview covers where adoption stands. It is the direction the agentic web is heading, but it is early, and most crawlers today still rely on DNS or IP ranges.
That is why no single signal is enough on its own. A reliable verification layer runs whichever check a given operator supports and treats them as a set.
How the signals fit together
Verifying a crawler in practice means layering three independent checks and letting the strongest available one decide. FCrDNS handles the search engines and any operator with proper reverse DNS. Published-IP-range matching handles the AI crawlers that ship CIDR lists instead. Web Bot Auth handles the signed requests that need no network-level inference at all. A user agent that passes none of them, but claims a famous name, is exactly the spoof you want to catch and block.
Running all three by hand, per request, across every operator’s changing IP lists and domain conventions, is more than a log grep can do at scale. FCrDNS is one of the exact signals Lume runs automatically to verify agents: every request that claims to be a known crawler gets the reverse lookup, the domain-suffix match, and the forward confirmation, alongside published-IP checks and Web Bot Auth where the operator supports them. The result is a single verdict per request (verified, unverified, or spoofed) instead of a pile of raw DNS answers you have to interpret. Reverse DNS is where that verdict starts, and forward confirmation is what makes it trustworthy.
Frequently asked questions
What is the difference between reverse DNS and FCrDNS?
Reverse DNS is a single lookup that turns an IP into a hostname using a PTR record. FCrDNS adds a second lookup that resolves that hostname back to an IP and confirms it matches the original. The extra step is what closes the loophole where an IP owner points a fake PTR record at a domain they do not control.
Can a reverse DNS lookup be faked?
The reverse half can be faked, because whoever operates an IP block sets its PTR records and can name them anything. What cannot be faked is the forward confirmation, since that record is controlled by the real domain owner. This is exactly why you never trust reverse DNS alone and always forward-confirm.
How do I verify Googlebot with reverse DNS?
Run a reverse lookup on the IP, confirm the returned hostname ends in googlebot.com or google.com, then run a forward lookup on that hostname and check it returns the same IP. If all three hold, the request is genuinely Googlebot. Google also publishes an IP-range list as an alternative if you prefer not to make live DNS queries.
Do all AI crawlers support reverse DNS?
No. Many AI crawlers publish IP ranges in a machine-readable file instead of maintaining PTR records, so FCrDNS returns nothing for them. For those, you verify by matching the source IP against the operator’s published CIDR blocks, and increasingly by checking a Web Bot Auth signature on the request itself.
Is reverse DNS lookup slow for verification?
A single FCrDNS check needs two DNS queries, which adds latency compared to matching an IP against a cached range list. At low volume the round trip is fine. At scale, verification layers cache results and fall back to published-IP or signature checks so that a live DNS lookup is not on the critical path of every request.