2

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

Community
  • 1
somecallmemike
  • 161
  • 1
  • 4

2 Answers2

2

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.com and then uses the A record to confirm that *.google.com matches the same IP address. If there's a mismatch somewhere, you have discovered a fake Googlebot.

Michael Hampton
  • 237,123
  • 42
  • 477
  • 940
  • I think you misunderstood my question. I am not asserting that A records do not match PTR records at all, rather that they only match for IP addresses / hostnames that matter. Take for example an IP address that is assigned via DHCP to a (ISP) customer's home connection. What purpose would hosting a forward lookup zone using the ISP's domain name (e.g. broadband-customer-1.ispdomain.tld maps to 1.2.3.4) serve? You absolutely want services such as webhosting and email to have forward and reverse matching, but this would never use an ISP domain name (e.g. broadband-customer-1.ispdomain.tld). – somecallmemike Sep 07 '12 at 19:40
  • Michael Hampton's reasoning applies to IPs given to ISP clients via DHCP. That's how you can more easily figure out who the client really is that is doing bad things. E.g., if n.n.n.n has a PTR to broadband-customer-1.ispdomain.tld but broadband-customer-1.ispdomain.tld doesn't have an A record with n.n.n.n, then you know ispdomain.tld isn't the party to contact. – Mark Wagner Sep 08 '12 at 00:05
2

Would there be any reason for the ISP to host a forward lookup for an IP address on their network like this?

Consistency and completeness, mainly. While you might have a hard time imagining why it's important, the RFCs were written for exactly one good reason: So everyone on the Internet has a consistent base understanding of how everyone else is going to interact with them. Without this base, the Internet would be a jumble of protocols, implemented however anyone would like, without any expectation of documentation, compatibility, interoperability, or consistency.

Services that are known to depend on these forward and reverse lookup's shouldn't be the special ones that get proper RFC treatment. It should be assumed that if you're going to participate with the rest of us, that you're going to play on the same level play-field as the rest of us.

Chris S
  • 77,337
  • 11
  • 120
  • 212
  • I think you also misunderstood my question. The RFC in question specifies services that need to have matching A and PTR records are configured as such, but I am wondering about whether an IP address that is allocated as part of a DHCP pool to a customer's broadband connection really needs an A record. It's obvious that all IP's delegated by an ISP need a PTR record, but why would anyone want an A record like "broadband-customer-1.ispdomain.tld" configured for an IP like this? What purpose does it serve other than ambiguously "playing on the same play-field". – somecallmemike Sep 07 '12 at 20:51