Not without controlling the operator's DNS zone. The forward resolve happens in the zone that owns the name — Google's, in the case of `googlebot.com` — so an attacker would have to compromise the operator's DNS rather than their own.

Why do some crawlers have no reverse DNS record?

Usually because of where they run. Cloud platforms do not set reverse records for customer addresses by default, so an operator on Azure or AWS has none unless it requests them. OpenAI is the clearest case: it publishes address lists precisely because the reverse-DNS path is closed to it.

Is checking the IP range enough on its own?

It is strong evidence and it is faster, but it can only confirm — never deny. An address that is not on a published list may be a new range the operator has not announced yet, so a miss falls through to unverified rather than to a negative verdict.

Verification

Forward-confirmed reverse DNS

Also known as FCrDNS, reverse DNS verification, double-reverse DNS

5 min read · updated 2026-09-09

Definition

Forward-confirmed reverse DNS (FCrDNS) is a two-step check that proves an IP address belongs to the operator a request claims to come from: resolve the address's reverse DNS record, confirm the name belongs to that operator, then resolve that name forward again and confirm it returns the same address. Google and Bing both document it as the way to verify their crawlers.

Why one direction is not enough

A reverse DNS record — the PTR record that maps an address back to a name — lives in the zone of whoever controls that address. That is the whole problem. Somebody running a scraper on their own server can set its reverse record to say `crawler.googlebot.com`, and a check that stops there will believe them.

The forward step closes it. Having read the name out of the reverse record, you resolve that name normally and see which address it returns. `crawler.googlebot.com` resolves inside Google's zone, which the scraper does not control, so the answer comes back as a Google address and does not match the address that made the request. The claim fails.

This is why the check is called forward-CONFIRMED reverse DNS rather than just reverse DNS lookup. The confirmation is the security property; the lookup on its own is a courtesy.

What it costs and when it is worth paying

Two DNS round trips per request, which is why nothing does this on the hot path for ordinary traffic. For crawler verification it is affordable because the volume is low — a few hundred requests a day on most sites, against millions of human page views — and because the answer can be cached per address.

The timeout matters more than the latency. A verification that hangs behind a visitor's page load is worse than no verification, so the check runs with a hard ceiling and a timeout is recorded as unverified rather than as a failure. Not knowing is an ordinary answer here.

Which operators support it

Google and Bing document FCrDNS as their recommended verification method and maintain the records for it. Yandex, Baidu and Huawei publish reverse records too, which makes them verifiable without any address list at all — a useful property, because none of the three publishes a machine-readable list.

OpenAI, Anthropic, Perplexity, DuckDuckGo, Mistral and Moonshot go the other way: published IP ranges, no reverse records. OpenAI's case is structural rather than a choice — it runs on Azure, and Azure addresses have no reverse record to read.

Meta, ByteDance, xAI, Cohere, DeepSeek, Zhipu and Allen AI publish neither. For those, the honest ceiling is an unverified claim, and any product telling you otherwise is guessing.

What goes wrong

Skipping the forward resolve. The reverse record alone proves nothing, and this is the single most common way crawler verification is implemented wrong.
Not normalising IPv4-mapped IPv6. An address arriving as `::ffff:66.249.66.1` cannot be resolved by a plain reverse lookup — measured here, the same Googlebot came back verified in one form and unverified in the other.
Treating a timeout as a failed verification. DNS being slow says nothing about who sent the request.
Reporting a miss as a forgery. An operator can start using a range before publishing it; absence of proof is not proof of absence.

Worth doing

Cache per address, not per request — crawlers reuse addresses heavily.
Keep the timeout under a second if the check runs anywhere near a user-facing request.
Check the IP list first where one exists: it is a single arithmetic comparison against cached data, and it settles most requests without touching DNS.

Questions

Can FCrDNS be faked?: Not without controlling the operator's DNS zone. The forward resolve happens in the zone that owns the name — Google's, in the case of `googlebot.com` — so an attacker would have to compromise the operator's DNS rather than their own.
Why do some crawlers have no reverse DNS record?: Usually because of where they run. Cloud platforms do not set reverse records for customer addresses by default, so an operator on Azure or AWS has none unless it requests them. OpenAI is the clearest case: it publishes address lists precisely because the reverse-DNS path is closed to it.
Is checking the IP range enough on its own?: It is strong evidence and it is faster, but it can only confirm — never deny. An address that is not on a published list may be a new range the operator has not announced yet, so a miss falls through to unverified rather than to a negative verdict.

See which AI assistants are reading your site.

AI crawlers take your HTML and leave without running a line of JavaScript, so a browser tag records nothing. TrueStat reads them server-side, checks each address against what the operator publishes, and shows you which pages were fetched — including the ones that returned a 404.

Start tracking All terms