RFC 1912 Section 2.1 states the following:
Make sure your PTR and A records match. For every IP address, there
should be a matching PTR record in the in-addr.arpa domain. If a
host is multi-homed, (more than one IP address) make sure that all IP
addresses have a corresponding PTR record (not just the first one).
Failure to have matching PTR and A records can cause loss of Internet
services similar to not being registered in the DNS at all. Also,
PTR records must point back to a valid A record, not a alias defined
by a CNAME. It is highly recommended that you use some software
which automates this checking, or generate your DNS data from a
database which automatically creates consistent data.
This does not make any sense to me, should an ISP keep matching A records for every PTR record? It seems to me that it's only important if the IP address that the PTR record describes is hosting a service that is sensitive to DNS being mismatched (such as email hosting). In that case the forward zone would be configured under a domain name (examples follow the format 'zone -> record'):
domain.tld -> mail IN A 1.2.3.4
And the PTR record would be configured to match:
3.2.1.in-addr.arpa -> 4 IN PTR mail.domain.tld.
Would there be any reason for the ISP to host a forward lookup for an IP address on their network like this?:
ispdomain.tld -> broadband-ip-1 IN A 1.2.3.4
Best Answer
Matching the PTR and A records makes it possible to verify the claim made in the PTR record by automated means.
If the A record isn't provided, one must go to the whois records to verify whether the PTR record accurately represents the entity in control of the IP address, a tedious manual process that's difficult to automate and is often wrong or out of date.
This is important for security reasons in many contexts. One that I'm familiar with and will give you an example for is:
Let's say you run a web site and post unique content, but you have discovered your content is being copied to other web sites, and worse, they're ranking higher than you in the search engines!
After hours of staring at your logs wondering how in the world somebody slipped a bot past your defenses, you finally notice hundreds of requests from Googlebot. But when you eventually look up one of the IP addresses, you find it registered to Bulletproof Ukraine Web Hosting and not Google. You thought you were getting indexed but instead you got played.
How do you solve this problem? Easy, you compare the PTR record to the A record. Google even recommends this approach.
This can be automated in many Web programming languages (PHP is a notable exception; you cannot do this reliably in PHP) so that a Web app can check the IP address, see that the PTR is
*.google.comand then uses the A record to confirm that*.google.commatches the same IP address. If there's a mismatch somewhere, you have discovered a fake Googlebot.