On 4 Jun 2016, at 1:52, Michael Fox wrote:
[Quoting me]
As noted by Allen Coates, if postscreen_dnsbl_ttl (v2.8-v3.0) or
postscreen_dnsbl_min_ttl (3.1) is higher than the negative cache TTL
for
a DNSBL, postscreen can 'PASS OLD' an IP which has been listed in the
period since its prior connection during which the resolver cache of
the
negative result has expired, so smtpd can see a listing that
postscreen
does not.
This is what I'm still a little fuzzy on.
In v2.8-3.0, and assuming the postscreen_dnsbl_ttl default of 1 hour,
I can
understand Alan's example. A new bad guy starts up and gets through
the
first time, which postscreen caches for a default of 1 hour. The bad
guy
then starts his attacks within that hour of time and gets added to
DNSBLs.
But postscreen doesn't see it for an hour, while smtpd does (assuming
the
actual DNSBL's TTL is < 1 hour). I think I understand that part.
But in v3.1, with the default postscreen_dnsbl_min_ttl of 60 seconds,
and
postscreen using the actual TTL from the DNSBL, it seems like that
issue no
longer exists. Here's my understanding: Using the same scenario,
postscreen caches the positive answer on the first connect. And,
according
to Wietse, smtpd uses the same caching resolver.
Maybe the confusion is here: postscreen and smtpd use the same caching
resolver because they run on the same machine and use whatever caching
resolver that system is configured to use. It is not part of Postfix.
Ideally this is a nameserver like Unbound or BIND on the same machine or
same LAN, but some people aren't concerned with performance or the
ability to use public DNSBLs and point their systems to Google or
OpenDNS or their ISP's resolvers.
Postscreen keeps its own internal DNSBL result cache for performance and
while it may seem counter-intuitive, doing so also is probably less
resource-intensive than depending on the system resolver and whatever
cache it ultimately uses. This cache is NOT usable by smtpd processes.
So when smtpd does the
lookup probably less than a second later, it should get the answer
from the
resolver's cache, which should be the same answer that postscreen got.
Now
the bad guy starts his attacks and gets added to the DNSBLs. If the
TTL has
not yet expired, then postscreen uses it's positive cached value and
smtpd
will still get a positive answer from the resolver's cache. If the
TTL has
expired, then both postscreen and smtpd would get a new, negative
answer.
There may be miniscule differences in timing. But I would think the
results
would be virtually identical.
Is that right? If not, what am I missing?
If postscreen_dnsbl_ttl or postscreen_dnsbl_min_ttl is 3600 (1 hour) but
the minimum TTL field of the DNSBL's SOA record is 10 (as it is for the
SBL) then postscreen will cache the lack of a DNSBL entry for as much as
59 minutes and 50 seconds longer than a proper caching resolver, which
will keep the negative response for 10 seconds at most (unless it's an
older Microsoft DNS server or a broken Unbound instance that has been
given a minimum TTL...)
Also, for pre v3.1 users, is there a best practice recommended value
for
postscreen_dnsbl_ttl that is better than the default of 1 hour?
I cannot tell you who you are... :)
However, for almost everyone, an hour is too long. The 22 DNSBL's I find
interesting enough to have in my own multi-list tool (which are NOT all
fit for postscreen) have negative cache TTLs (the minimum TTL field of
the SOA record) that range from 0 to a whole day. There's absolutely no
reason for postscreen_dnsbl_ttl to be shorter than the negative cache
TTL of the DNSBLs you use. The postscreen_dnsbl_min_ttl default in 3.1
is 60s, which I think is reasonable for postscreen_dnsbl_ttl even though
it is longer than the TTL of some of the most useful DNSBLs (like the
Spamhaus lists.) However, if your resolver is distant, slow, or
overloaded you might not want to go that short. If you have smtpd
checking the same DNSBLs and have reasonable CPU and memory to spare,
you might even go as high as 600s: smtpd is heavier than postscreen but
it's not so bad unless you handle really high volumes of mail.
