Improved Accuracy and False-Positive Mitigation

RBLTracker relies on data provided by third parties; whether it’s the RBL providers themselves, or Google and Yandex (for Safe Browsing data), or the data provided through the Facebook Threat Exchange. As such, we are somewhat subject to the accuracy of this data.

The Accuracy Problem

Occasionally, we’ll end up in a situation where the data provided by these third parties is inconsistent between the different nodes, or DNS servers on their system. This can end up causing, what is often referred to as “flapping” – a host going in and out of a listed state each time it’s checked.

This flapping can be really annoying to system and network admins, as it gives them an in-accurate view of what’s actually happening.

Today’s Release – Release 3.4

RBLTracker has worked hard to work around the flapping problem, so as to present the most accurate view of the current listing state of all our customers’ hosts. Today’s RBLTracker release, improves upon the existing false-position mitigation algorithm in a few key ways:

1. We’ve implemented the false-position mitigation logic on both the listing and delisting events. Previous to this, the logic was only used when a host became listed for the first time.
2. We’ve adjusted the logic to use a best 4 out of 5 (increased from best 2 out of 3) logic when listing or delisting a host. Now a listing or delisting event is only triggered if the data returned by the RBL provider is consistent across at least 4 out of 5 of their DNS nodes.

Based on our exhaustive testing, we’ve found that this dramatically reduces the number of false positive and flapping events, which will present a more accurate, and up-to-date view of our customers’ current listing status.

To find out more about everything we do to ensure the most accurate results for all our customers, read our article on accuracy an reliability.