[PLUG] Using DNS information to close smtp port...

[Ronald Chmara]

On Wed, Aug 17, 2011 at 8:09 PM, Michael C. Robinson
<plug_1 at 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