Please understand, I'm only proposing this as an alternative idea for
checking to see if a sending server's IP address has proper rDNS... NOT any
other type of DNS lookups.

Also, I don't have stats on this, but I know that most mail is spam and I
know that MUCH of this spam has no rDNS properly configured.

Furthermore, when rDNS is not properly configured and a subsequent lookup is
done on the same IP, I'm pretty sure that the negative (no found) lookup
isn't cached at all or at least not for long.

For example, if you do a lookup on blahblah.yourdomain.com and that domain
doesn't exist. Next, seconds later, create an A-record for
blahblah.yourdomain.com ...finally, seconds later, do another lookup for
blahblah.yourdomain.com

In my testing, that last lookup DOES find something... indicating that DNS
servers don't generally cache previously "not found" lookups... at least not
for long.

rDNS on a spammer's IP which doesn't have rDNS configured involves a similar
situation. Therefore, I don't think DNS servers cache the negative results
of rDNS checks either at all or for very long. But, ironically, these types
of checks are more expensive than most lookups. I've found that DNS server
often take longer to return a "not found" result when the IP address is from
some 3rd party network in Korea... in contrast to an "is-found" lookup from
a DNS server on your own network.

Also, if absolutely no caching of negative lookups takes place, this would
be even more beneficial for spam attacks from a single IP just prior to
tarpitting kicking in... but that particular need is not a prerequisite to
my idea being a good one overall... just "iceing on the cake".

--Rob McEwen


Reply via email to