Author: Alexander Perlis Date: To: exim-users Subject: Re: [exim] How to handle DNS timeout delays when spam RBL is under
DDoS attack?
Mar Matthias Darin wrote: > Increasing the size of your local cache will give you a
> big advantage.
I think there's a misunderstanding. Our local cache is not running out
of room. Therefore, increasing the size of the cache won't help.
Instead, the upstream anti-spam RBLs are disappearing entirely (perhaps
due to DDoS attack), so after the local cache entry expires, our local
cache gets no response from the RBL and thus obtains nothing to cache,
whence lookups to the local cache for those entries end up hanging until
they time out.
> Also, in your /etc/resolv.conf, try having the following:
> search localhost
> nameserver 127.0.0.1
> if the name server is on the same server as exim, otherwise modify the > resolv.conf to contain only the local name server(s).
Our Exim box's resolve.conf points only to our local DNS cache.
> Also, a TTL in your name server of at least 86400 may boost
> performance. You don't want to go more then 48 hours though
> or you'll start running into cache bloat.
Our DNS cache uses the same TTL as it obtains from upstream. In other
words, it is a transparent cache.
Even if we did as you suggest, after the (longer) TTL expires we'd be in
the same boat as before: every lookup to our local cache for an
anti-spam RBL that has disappeared will end up timing out after a long
delay.
> Hope this helps.
I appreciate the attempt to help, but I think you misunderstood the
problem we're facing. Our problem is not that we have remote caches or
that our cache is running out of memory. The problem is more fundamental
to the design of DNS and the fact that upstream disappearance can't
get cached and that Exim doesn't seem to support remembering this type
of problem.
So I ask again: does anyone know how to get Exim to keep track of
timed-out DNS lookups against the local cache and not repeatedly retry
such lookups on each SMTP conversation?
