SBRS unable to retrieve

magnussolberg_ironport · ‎10-31-2007

Hi ppl,

Last Sunday evening around 8pm one of our C100s @ a customer of ours starting letting through huge amounts of spam. This lasted until the following Wednesday morning.

It looks like SBRS suddenly stopped working - or at least pretty much so. Reputation filtering statistics dropped from around 90% down to _9%_ these few days, thereby flooding user with spam...

After doing some basic forensics, it seems like they had some stability issues with our DNS, but this doesn't account for the huge difference in filtering, does it?

Also, the whole week most mail got tagged with "SBRS unable to retrieve" and so ended up in the SG None-group. I'm hesitant to add sbrs scores of none to the suspectlist, because since most mail is not tagged with a score this may cause a lot of problems for legitimate senders and recievers...

The weird thing is, I would've understood if both dns and sbrs was the root of the problem (dnsserver down, fw policy stopping the sbrs query), but the floodgates were only open in the period from Sunday evening to Wednesday morning. And the "unable to retrieve"-message continued until Friday with mailflow seemingly being normal again.

Can't see anything else that's out of the ordinary in the logs - but maybe I don't know what I'm looking for. Any ideas?

--magnus

Mark [CSE]_ironport · ‎11-01-2007

SBRS is using DNS to get the score. If DNS is down, SBRS will not get a score, which in turn will trigger the policy with the NONE score.

Best Regards,

Mark

Doc_ironport · ‎11-03-2007

This is one of the reasons that we (strongly!) recommend having the IronPort's configured to do DNS lookups themselves (via the root servers) rather than directing them to a local DNS server on your network.

Not only does this make DNS/SBRS lookups more reliable, it reduces the load on your DNS servers.

seveneyes_ironport · ‎11-07-2007

This is one of the reasons that we (strongly!) recommend having the IronPort's configured to do DNS lookups themselves (via the root servers) rather than directing them to a local DNS server on your network.

Not only does this make DNS/SBRS lookups more reliable, it reduces the load on your DNS servers.

While this may be true, there is no fucntion within asyncos that allows the flushing of individual dns records as bind allows. When a dns manager makes a mistake and then a correction this is a nice feature to have to flush the bad entries if cached. Flushing the whole cache is all that is available in asyncos.