As you might guess, DNSBL stands for DNS Blocklist. While it’s not a new technology, the usefulness of various DNS/RBL blocklists in fighting spam is indisputably immense. Over the years I’ve heard both the success stories from folks who implemented RBLs in their Exchange server deployments, and I’ve heard some horror stories from the folks who’s IPs were maliciously or mistakenly added to RBLs and the difficulties they had working with blocklist providers to delist their IPs from the RBLs. Another contributing factor to the overall painful experience with RBLs is the fact that you need to configure them with appropriate response codes and delisting logic etc. It’s manual work and as such is very error-prone. Also, some of the blocklist providers will expose their lists for free to small customers only. For example, they will allow only a certain number of queries against the blocklist per day and if the query volume exceeds the allowed (and very small in reality) free amount they will either block the queries (firewall) or ask the customer to receive the blocklists via paid subscription. If you are going to use a free DNS blocklist, you need to make adjustments (lower expectations) regarding the quality of service. Considering these factors, some Exchange admins prefer to stay away from blocklists because they just do not want to go through the headache generally associated with maintaining multiple RBL providers’ configurations.
The Forefront DNSBL
So what’s up with the Forefront DNSBL? What is it and how is it different from the rest? In short, the Forefront DNSBL is an aggregated list of multiple feeds from various RBL providers combined into a single lookup and hosted by Forefront Online Security for Exchange (FOSE) on its own DNS infrastructure. The list of feeds includes both Microsoft-internal contributing teams and external vendors (for example, Spamhaus). Forefront DNSBL is already available to customers in the next generation of Forefront Security for Exchange Server (Beta 2) (you can get Beta2 here) and it is royalty-free (hey, we all like free stuff, do we not?) to Beta 2 customers. So if you are thinking of evaluating Forefront Security for Exchange Server (Beta 2), I encourage you to download it and give it a shot.
With Forefront DNSBL implementation you will get configuration and maintenance-free DNSBL solution that is enabled out of the box without any manual work needed from the administrator to configure and maintain the filter. Forefront DNSBL will start working immediately after the setup (just do not forget to opt-in to antispam during the setup phase) and there is nothing to configure. This is how it looks in the Forefront Security for Exchange Server UI:
As you can see, there is nothing to configure, just a simple checkbox to enable/disable the DNSBL checking. Similar to the basic Exchange 2007/2010 server RBL functionality, Forefront DNSBL has been implemented as an agent and executes based on the connecting IP address. However, this is where the similarities end. So what’s in the guts of Forefront DNSBL and how does it work?
While Forefront DNSBL agent also makes the trip to the DNS blocklist provider (maintained by FOSE), the DNS query itself has been encrypted. You might ask why is it encrypted? Well, due to the nature of DNS (which is not secure) and having an obligation to preserve our contributing vendors’ proprietary data from unauthorized access by the non-Forefront customers, we decided to hash the DNS query. On the DNSBL provider end, the hosting DNSBL server runs the same algorithm to decrypt the incoming query and verify its integrity. If the query is confirmed to be legitimate, (only the Forefront agent knows how to encrypt and decrypt the query) the DNSBL provider will service it. If the query has been constructed incorrectly or the hash does not compute correctly, the returned query will contain NXDOMAIN response. Yes, we go the extra mile in protecting our vendors’ intellectual property (RBL data) and will service only Forefront customers (As a legit Forefront customer, you really do not care whether the query is encrypted or not but you do care about the quality of service, right?).
So the original query to the DNSBL provider is hashed. However, the returned query is not and if a match is found on one of the contributing feeds, the DNSBL service provider will return the appropriate response. For example, if the match is found on the FOSE internal blocklist, the returned query will contain 127.0.0.5 response. If the match is found on Spamhaus’ XBL list, the return query will be 127.0.0.4 and if it’s found on SBL, the query will be 127.0.0.2. Accordingly, the Forefront DNSBL agent will reject the e-mail transaction inside of SMTP session with a response explicitly crafted for the particular DNS query return code. This is how the response looks like if the IP match was found on one of the blocklists:
There are 3 parts in the Forefront DNSBL response issued by the agent:
1. Default machine code (understandable by the server’s SMTP stack)
2. Default human-readable response string
3. FSE-specific delisting information.
The human-readable response string contains vital information about the blocklist (feed) name that contains a match for the IP address. Having this information will help alleviate the pain of delisting if the IP was blocklisted mistakenly and expedite the delisting process and time.
The FSE-specific delisting information references specific action for the end user to take. In most cases, the end user needs to forward the NDR to the delist@frontbridge.com alias. The forwarded message (NDR) will then be evaluated by the Forefront analysts (DNSBL support services) and corrective action will be taken to delist the IP from the appropriate blocklist. If the IP was blocklisted by one of the external feeds, the delisting string will contain appropriate information about how to correct the problem. In essence, delisting is a very easy and almost pain-free process as we made it as simple and straightforward as possible.
Now let's talk about the effectiveness of the Forefront DNSBL. Having multiple data feeds combined into a single database and a single lookup not only increases the efficacy and robustness of the solution but improves the performance of Exchange server because now it's a single DNS trip instead of multiple (if you have more than one RBL provider configured as most Exchange admins do). Based on the feedback from Beta 2 customers, the contribution of Forefront DNSBL to overall spam rejection rate is around 90% (it varies by the geographical location/regions of the world). This effectively means ~90% of all incoming e-mail transactions get immediately rejected at the gate without pushing unnecessary payload through the network layers. This preserves network bandwidth and Exchange server processing time, which translates into money saved (Plus, the service is free.).
Quite frankly, it took me more time to write this blog than for a Forefront admin to enable and start using DNSBL! The bottom line – Forefront DNSBL is maintenance-free, hands-off, built-in feature capable of producing very impressive results in antispam protection. So, YEAH or NAY? I’d say YEAH BABY! Let me know if you disagree.
Alex Nikolayev
Program Manager, Forefront Server Security
