Share via

Forefront DNSBL… Yeah or Nay?

  • Article

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:

DNSBL screen

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:

Blocklist response 

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

Comments

  • Anonymous
    January 01, 2003
    The comment has been removed

  • Anonymous
    January 01, 2003
    nice article thank you respectfully

  • Anonymous
    January 01, 2003
    Sounds like a great feature. But when I enable it I no longer can receive ANY email from the internet. I get the following error message returned to the sender: Technical details of permanent failure: Google tried to deliver your message, but it was rejected by the recipient domain. We recommend contacting the other email provider for further information about the cause of this error. The error that the other server returned was: 550 550 5.7.1 :208.69.36.132:Client host 209.85.220.212 UnknownDNSName; Mail from IP banned. To request removal from this list please forward this message to delist.forefront@messaging.microsoft.com (state 14).

  • Anonymous
    January 01, 2003
    While I can't speak to specific design decisions made by the team, the following links detail some of the thinking that went into the anti-spam functionality and design in FPE 2010.

  • The video Forefront Protection 2010 for Exchange (FPE) Anti-Spam (technet.microsoft.com/.../ff711255) goes into some detail about the architecture and design considerations that were made when the team designed FPE 2010.
  • Connection filtering (technet.microsoft.com/.../hh184079.aspx) on TechNet also describes anti-spam connection filtering in FPE 2010. I hope you find these to be helpful.

  • Anonymous
    January 01, 2003
    Hello djs, I looked around for resources for you. Hopefully these can be helpful: This is a forum thread in the Office 365 community that describes a similar situation to yours: Help: our company servers are getting blocked by MS Exchange Online servers (community.office365.com/.../14550.aspx) Here is another forum thread concerning block lists: FPE 2010 DNSBL (social.technet.microsoft.com/.../6decd943-7aaf-428b-b3bd-6f6af0cc9b18) Here is a Knowledge Base article concerning NDRs: support.microsoft.com/.../en-US You can also contact FOPE technical support for help: technet.microsoft.com/.../ff715245.aspx Regards, Tony

  • Anonymous
    January 13, 2010
    This is in response to the issue raised by KilroyWasHereAustin.  Not receiving any mail from the internet means all remote MTAs trying to submit to you are on the blockist.  This is very unlikely.  The NDR you referenced contains actionalbe response "550 5.7.1 ...."  If you forward this message to the delist dot forefront AT messaging dot microsoft dot com our analysts will look into this case and delist the IP address in question.  The process is quick and no other actions from you required.  Sorry you hit this but hey - we are here to help you!

  • Anonymous
    February 17, 2010
    The comment has been removed

  • Anonymous
    March 10, 2012
    The comment has been removed

  • Anonymous
    March 14, 2012
    With most RBL implementations, I have to option to choose not to use a particular list.  In a recent case, I had a business partner blocked by 88.blocklist.zap. I'm afraid that this aggressive RBL list might be blocking other business partners, but I don't see any way in the new Forefront DNSBL implementation to say that I'd rather not use 88.blocklist.zap. Why does this have to be all or nothing?