>...
>
>Rob McEwen wrote:
>> I've got an idea for faster rDNS lookups.
>>
>> Before I present the solution. Here is the problem...
>>
>> ...basically, rDNS checks are "expensive". They sometimes take a few seconds
>> when done in real time and depend on the timeliness and of other people's
>> DNS servers. This 1-5 (or more) seconds may not seem like a big deal... but
>> if this can be more instantaneous, it increases the volume of messages a
>> server-side spam filter can handle. (every little bit counts)
>>
>> Anyone doubt me? Well... my point is valid for the same reason that it is
>> typically MUCH faster to check again a DNSBL (like SURBL) than it is to
>> convert domains found within the e-mail to IP addresses and then check these
>> again SpamHaus's RBL. Both of these are good techniques... but DNSBL
>> checking where each domain doesn't have to be resolved to an IP address is
>> much faster. For the very same reasons... again... rDNS checks are a bit
>> "expensive".
>
>Exactly how is this faster than using a dns caching nameserver?
>
>Cami
>
Cami's point is very close - DNS lookups are slow, but not
"expensive" (your machine can do other operations while waiting).
Other problems with the idea and valid (i.e. non-spam) domains are:
a) virtual hosting with many to one DNS maps, but a single IP->name rDNS
and the hosting company moves domains around to "load balance". This
will cause rDNS to "flap" whenever a virtual domain is moved.
b) multi-homed machines and clusters - rDNS is valid, but needs a many
to one mapping to be correct (i.e. your database would have to allow
for that, so the replies could be larger than the existing case, and
thus actually be "more expensive" - i.e. more processing required).
And for spam domains, IP-jumping is common (i.e. they get in the
SBL, so the host changes its IP); Therefore your hypothetical server would
have to query every entry at least as often as the TTL to keep up to date.
Simply, the rDNS for spam (not most ham) domains and name servers (SA looks
those up also) does change often, so for these cases, your assumption is
incorrect for the important case (for well run, legitimate domains, what
you say is indeed correct - rDNS seldom changes).
The shortest possible reason is "slow != expensive". At best, you
would shorten delivery times by a few seconds, but even on a slow machine
I doubt the CPU savings would be more than a couple of milliseconds (OK,
if you have a lousy NIC card and a slow CPU, maybe 10 milliseconds). *AND*
the load on the hypothetical "pre-mapped rDNS" server would be extreme.
Paul Shupak
[EMAIL PROTECTED]
