On 11/4/20 8:30 PM, Richard Hector wrote:
Is it reasonable to expect that a residential ISP, that provides a generated reverse resolution to a home IP address, will also provide a matching forward resolution that goes back to the same IP?
PTR records have always been useful for annotating traceroute responses as well as for classification in web log analytics or email "Received" headers. About 30 years ago, UUNET ran a popular FTP server (ftp.uu.net) that hosted open source software and mailing list archives among other content. It was decided that if the source connection didn't have a PTR record, the server wouldn't accept the connection. I believe this draconian measure was the start of uptake in PTR use. You're asking, though, about whether one should register A records. RFC-1912 documented publishing matching PTR/A records as a common practice. It's not difficult to auto-generate DNS zones: DDD.CCC.BBB.AAA.in-addr.arpa. IN PTR AAA-BBB-CCC-DDD.dyn.provider.net. AAA-BBB-CCC-DDD.dyn.provider.net. IN A AAA.BBB.CCC.DDD Starting in the late 1990's, mail services started using PTR records as part of their anti-spam enforcement. If there was no matching A record for the PTR record of the connecting IP address: 1) the connections were refused, 2) delivery was greylisted, or 3) messages scored higher in SpamAssassin and more likely found their way into spam folders. One could make a case to *not* register matching A records for your dynamic clients to help limit their ability (or malware's ability) to successfully send spam emails via SMTP from your dynamic network. There are interesting points in RFC 8501 about how PTR practices might extend to IPv6. -- Eric Ziegast PS: [BOFH] I once suggested self-referring matching records: 1.AAA.BBB.CCC.in-addr.arpa. IN PTR 1.AAA.BBB.CCC.in-addr.arpa. 1.AAA.BBB.CCC..in-addr.arpa. IN A CCC.BBB.AAA.1 2.AAA.BBB.CCC.in-addr.arpa. IN PTR 2.AAA.BBB.CCC.in-addr.arpa. 2.AAA.BBB.CCC..in-addr.arpa. IN A CCC.BBB.AAA.2 ...etc...