Forward Confirmed Reverse DNS

FCrDNS requires a two-step validation process: first, a reverse DNS (PTR) lookup resolves the IP address to a hostname. Then, a forward DNS (A or AAAA) lookup on that hostname must return the original IP address. This circular verification ensures the DNS records are symmetrically consistent, preventing trivial spoofing where an attacker controls only the reverse record. Without forward confirmation, any IP owner can set a PTR record claiming to be google.com.

FCrDNS is a foundational trust signal in anti-spam filtering and email server authentication. Mail transfer agents (MTAs) like Postfix and Sendmail perform FCrDNS checks on connecting SMTP clients. A failed confirmation often results in greylisting, higher spam scores, or outright rejection. Legitimate mail servers are expected to have matching forward and reverse records, while botnet nodes and compromised residential hosts typically fail this check. It complements SPF, DKIM, and DMARC as a network-layer trust indicator.

For AI crawler identification, FCrDNS serves as a critical verification layer beyond User-Agent strings. When a bot claims to be Googlebot, performing an FCrDNS check on its IP should resolve back to a *.googlebot.com or *.google.com hostname. This prevents User-Agent spoofing by scrapers who set their UA string to mimic legitimate crawlers. Combined with IP reputation databases and ASN blocking, FCrDNS provides cryptographic-grade certainty about crawler origin.

FCrDNS hostnames often reveal the network type of the originating IP. Residential ISP connections typically resolve to hostnames containing patterns like cpe-*-*-*-*.rr.com or pool-*-*-*-*.verizon.net. Datacenter and cloud IPs resolve to hostnames like ec2-*-*-*-*.compute.amazonaws.com or *.your-server.de. This allows datacenter IP detection without relying solely on external reputation databases, enabling real-time blocking of cloud-hosted scrapers while allowing legitimate residential traffic.

Reverse DNS zones are delegated differently than forward zones. The IP owner—typically the ISP or hosting provider—controls the PTR record, not the domain owner. For example, an EC2 instance's PTR is managed by AWS, not the application operator. This means FCrDNS verification requires coordination with the infrastructure provider to set correct PTR records. Legitimate crawler operators like Google and OpenAI maintain their own IP space and PTR delegations, making FCrDNS a reliable authenticity signal.

FCrDNS for IPv6 uses PTR records in the ip6.arpa zone, with the address represented as fully expanded, reversed nibbles. The larger address space makes reverse delegation more granular. However, many IPv6 deployments have incomplete or missing PTR records, making FCrDNS less reliable for IPv6-only hosts. Security architects should implement dual-stack FCrDNS policies that apply stricter scrutiny to IPv6 connections lacking valid reverse mappings, as this is a common evasion vector for scrapers.

The second, critical step where the hostname obtained from the reverse lookup is resolved forward to an A or AAAA record. The resulting IP must exactly match the original queried IP.

• Consistency check: If reverse(IP) → hostname and forward(hostname) → IP, identity is confirmed
• Failure modes: Mismatched records, missing A records, or wildcard DNS entries that resolve to different IPs
• RFC 1912 compliance: The IETF standard that defines this bidirectional verification as best practice for mail server authentication

A dynamic trust score assigned to an IP address based on historical behavior, threat intelligence feeds, and association with malicious activity.

• FCrDNS as a signal: Successfully passing forward-confirmed reverse DNS is a positive indicator that contributes to a higher reputation score
• Residential vs. datacenter weighting: IPs from consumer ISPs with valid FCrDNS typically receive higher baseline trust than cloud IPs
• Real-time scoring engines: Services like Spamhaus, IPQualityScore, and Cloudflare's threat intelligence aggregate FCrDNS validation results into composite risk scores used for preemptive blocking

The practice of denying access to all traffic originating from a specific Autonomous System Number, typically used to block entire cloud hosting providers known for hosting scrapers and AI training bots.

• Granularity trade-off: ASN blocking is blunt; FCrDNS provides per-IP precision to allow legitimate services within an ASN while blocking malicious ones
• Common targets: AS16509 (Amazon), AS14061 (DigitalOcean), AS63949 (Linode) are frequently blocked by content providers protecting against unauthorized scraping
• Bypass resistance: Attackers using residential proxy networks appear to originate from consumer ISP ASNs, making FCrDNS validation a critical secondary check even when ASN blocking is not triggered

A network routing service that channels bot traffic through IP addresses assigned by consumer ISPs to real home users, making automated scraping requests appear as legitimate organic traffic.

• FCrDNS evasion: Residential proxies often pass reverse DNS checks because the IP genuinely belongs to a consumer ISP with proper PTR records
• Detection gap: Forward confirmation alone cannot distinguish a compromised residential endpoint from a legitimate user; behavioral analysis and traffic pattern heuristics must supplement FCrDNS
• Proxy detection services: Commercial databases like IP2Proxy and MaxMind maintain lists of known proxy exit nodes, adding a layer beyond DNS verification to identify tunneled traffic