On Wed, Aug 17, 2011 at 8:09 PM, Michael C. Robinson <plu...@robinson-west.com> wrote: > Well, the DNS checking is increasing my rejection rate. Figuring out if > I'm blocking at the right times is another issue. Is there ever a > situation where a PTR record that doesn't resolve back to the IP you > started with is legitimate? For example, one popular PTR record is > localhost which obviously will not resolve to a remote IP address.
Oh, hey, look, this technique already has a geeky name: http://en.wikipedia.org/wiki/Forward_Confirmed_reverse_DNS That being said: 1) People working with nested hosting companies have lots of pain when trying to get proper PTR chain set up.... here's the crux of the problem, as it usually works out: Mega-hosting company A takes a hunk of "class C" (yes, traditional classes don't really exist anymore, but this is an incredibly relevant concept in this context, for a legacy reason I am about to explain) and re-sells the block. Lets say 192.168.1-5.0-255 is what the parent company starts with, which is supposed to be in the bind zone files for 0-255.1-5.168.192.in-addr.arpa. In case the problem isn't immediately apparent, the parent company has responsibility for delegating the following zones (DNS is right-to left) to the reseller: 1.168.192.in-addr.arpa. 2.168.192.in-addr.arpa. 3.168.192.in-addr.arpa. 4.168.192.in-addr.arpa. 5.168.192.in-addr.arpa. The DNS boundary winds up being at the quad, *regardless* of CIDR... reverse DNS still thinks in terms of dotted quad boundaries. Sub-company B then buys and resells a block of, oh, 128 IP addresses to another sub-company "C", from the parent. Lets' say it's 0-128.3.168.192.in-addr.arpa. Of course, since the whole block wasn't resold, the place to manage this is still one level up, at 3.168.192.in-addr.arpa. (Again, DNS delegates at "." boundaries, business agreements be damned). Company D buys half of those, and then they then resell it *again*, to end client E, who just needs six IP's for their servers. A->B->C->D->E is how the sales chain works. However, in order to divide on the dotted quads, for E getting a proper PTR record, they ("E") have to somehow get the message all the way up to company B, which is the company that actually manages PTR records for the whole 3.168.192.in-addr.arpa. zone. This can take weeks, and lots of communication. (I've done it more than a few times, and it's lame, *especially* if you have to juggle lots of server names changing). It gets even messier when you start with something as divided as 10.0-16.0-16.0-16.0-16, as *each* and *every* boundary must do proper delegation on the dotted quad, or have huge DNS zone files. 2) You're checking A records. What about AAAA? Is this an IPv4-only solution? 3) Corner cases to ponder (since I'm not sure all of these will pass at a light glance over the code, these may be already thought of): ...a). A server with 4 NIC's, hosting many virtual/VPS/whatever domains. The domain emails may claim to be coming from "example.com", but the IP may be 3.3.168.192.in-addr.arpa, which resolves to "eth3-bulkhosting.ourserverskickass.com". ...b) inbound.example.com vs. outbound.example.com resolving to the same, or different, host email IP.... ...c) Geo-location IP makes a mess of everything that makes assumptions about a fixed IP. Getting back to your original question: "Is there ever a situation where a PTR record that doesn't resolve back to the IP you started with is legitimate?" PTR's are not based on IP. They're based on DNS databases. Which are often made and controlled by humans. That makes them error-prone. It's worth "weighting" an email as spam, or not, but there's lots of messy side-issues.... "localhost" is one part (as you have discovered), but we're a long way away from one server=one IP. -Ronabop _______________________________________________ PLUG mailing list PLUG@lists.pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug