MULTI-SURBL SURBL issues - ORF Forums

MULTI-SURBL SURBL issues RSS Back to forum

1

I've been getting many emails blocked by the MULTI-SURBL SURBL. Example below.

Version: 4.4 REGISTERED
Log Mode: Verbose
Server: *******
Source: SMTPSVC-1
Time: 7/18/2011 9:43:12 AM
Class: Blacklist
Severity: Information
Actions: Tag Subject + Redirect Email
Filtering Point: On Arrival
HELO/EHLO Domain: (not available)
Related IP Address: 216.82.241.99
Message ID: (not available)
Email Subject: Quote Update
Sender: *******@webcoindustries.com
Recipient(s):
* *******@eriebearings.com
Message:
Blacklisted by the MULTI-SURBL SURBL (domain: "webcoindustries.com", DNS lookup result: 72.3.199.7).

I can't seem to track down why they are getting blocked? I've looked into all DNS lookups and they turn out not listed.

Again, it's not just this specific domain getting blocked, this is just one example. I have 4-5 domains getting blocked with the same message.

Any help is greatly appreciated.

Thanks,
Aaron

Reply
by Aaron more than 10 years ago
2

@Aaron: I checked this domain and could not find it listed, so I assume it is a DNS issue on your end: when the URL blacklist test is performed, ORF tries to query the A record associated to "webcoindustries.com.multi.surbl.com" using your DNS server. If the domain webcoindustries.com is listed, SURBL will return an IP to the query, i.e., 127.0.0.x (the last number indicates which blacklist the domain is listed on), and ORF will blacklist the email. If the queried domain could not be resolved, webcoindustries.com is not listed on SURBL and ORF allows the email through.

Now, there is no way the SURBL lookup should resolve to 72.3.199.7: it is an IP associated to the ISP "Rackspace Hosting". The lookup result should be either 127.0.0.x or "non-existent domain" (the latter in this case).

Please make sure the DNS servers configured in ORF (Configuration / Global / DNS and lookups) can resolve external zones and allow recursive lookups (i.e. returning the DNS data in a single step instead of redirecting ORF to the root DNS servers). We recommend having only one or two DNS servers specified and at least one of them should be local (to avoid problems with unexpected 3rd party (e.g., ISP) DNS configuration changes).

As a temporary workaround, you can also tweak your SURBL definition in ORF:

1. Start the Administration Tool
2. Navigate to Configuration / Filtering - On Arrival / URL Blacklists
3. Double-click SURBL Combined
4. Click the "Lookup results" tab, uncheck "Blacklist if DNS record exists (regardless record data)"
5. Click New, enter 127.0.0.2, click OK.
6. Click New, enter 127.0.0.4, click OK.
7. Click New, enter 127.0.0.8, click OK.
8. Click New, enter 127.0.0.16, click OK.
9. Click New, enter 127.0.0.32, click OK.
10. Click New, enter 127.0.0.64, click OK.
11. Click OK, press Ctrl + S to apply the changes.

The above will force SURBL to blacklist emails only if the lookup returns any of the above IPs.

Reply
by Krisztian Fekete more than 10 years ago
(in reply to this post)

3

@Krisztian Fekete: I have checked out everything you said but I'm still not sure if my DNS is setup correctly. I have 2 DNS IPs in the config:
65.24.0.168 (dns-comm-cac-01.ohiordc.rr.com)
65.24.0.169 (dns-comm-cac-02.ohiordc.rr.com)

You stated there should be a local DNS server, I'm not exactly sure what you mean. Could you help me with that?

Here is the result from the DNS test (I did notice the errors but I'm not sure how to diagnose them):

** DNS test starting: 7/19/2011 11:37:31 AM.

Running test #1.
DNS server: 65.24.0.168
DNS transport: UDP
Domain: vamsoft.com
Status: PASSED. Record found.

Running test #2.
DNS server: 65.24.0.168
DNS transport: UDP
Domain: www.vamsoft.com
Status: PASSED. Record was not found.

Running test #3.
DNS server: 65.24.0.168
DNS transport: UDP
Domain: b42qnc930j8rdiq53a69pcumbwe5isfmmb.com
Status: PASSED. Domain was not found (NXDOMAIN).

Running test #4.
DNS server: 65.24.0.168
DNS transport: TCP
Domain: vamsoft.com
Status: ERROR. Connection timed out. The DNS server may be down.

Running test #5.
DNS server: 65.24.0.168
DNS transport: TCP
Domain: www.vamsoft.com
Status: ERROR. Connection timed out. The DNS server may be down.

Running test #6.
DNS server: 65.24.0.168
DNS transport: TCP
Domain: b42qnc930j8rdiq53a69pcumbwe5isfmmb.com
Status: ERROR. Connection timed out. The DNS server may be down.

Running test #7.
DNS server: 65.24.0.169
DNS transport: UDP
Domain: vamsoft.com
Status: PASSED. Record found.

Running test #8.
DNS server: 65.24.0.169
DNS transport: UDP
Domain: www.vamsoft.com
Status: PASSED. Record was not found.

Running test #9.
DNS server: 65.24.0.169
DNS transport: UDP
Domain: b42qnc930j8rdiq53a69pcumbwe5isfmmb.com
Status: PASSED. Domain was not found (NXDOMAIN).

Running test #10.
DNS server: 65.24.0.169
DNS transport: TCP
Domain: vamsoft.com
Status: ERROR. Connection timed out. The DNS server may be down.

Running test #11.
DNS server: 65.24.0.169
DNS transport: TCP
Domain: www.vamsoft.com
Status: ERROR. Connection timed out. The DNS server may be down.

Running test #12.
DNS server: 65.24.0.169
DNS transport: TCP
Domain: b42qnc930j8rdiq53a69pcumbwe5isfmmb.com
Status: ERROR. Connection timed out. The DNS server may be down.


** DNS test finished.

There were problems.
Error(s): 6, warning(s): 0.
See the log above for details.


Thanks for your help.

Aaron

Reply
by Aaron more than 10 years ago
(in reply to this post)

4

By "local DNS server" I mean a DNS server which you have full control of (i.e., DNS server on your local network). Using the external DNS servers of your ISP (in your case "Road Runner") is strongly discouraged. ORF relies on DNS lookups heavily, and it seems the current DNS servers time out for all TCP lookups, which leads to degraded filtering performance.

I also suspect these DNS servers do not support recursive lookups and that is why the query to SURBL returns 72.3.199.7.

Reply
by Krisztian Fekete more than 10 years ago
5

Actually, I think I may have an answer for why that IP was returned when clearly it shouldn't have been. He's using Road Runner DNS servers, and many ISP's here in the US have implemented a non-compliant DNS "feature" whereby the DNS servers return a value for any query, valid or invalid. If you type in a non-existant domain name in your browser, the DNS server will answer by returning the IP for the ISP's ad laden "search" page.

Try using 4.2.2.1 and 4.2.2.2 for your DNS servers just to see what happens, I'm betting your URL blacklist will start behaving normally again.

Reply
by Bill Roland more than 10 years ago
6

@Bill Roland: I have tried both servers using nslookup, they returned either server failure (SERVFAIL) or reported nonexistent domains as expected when looking up subdomains of the multi.surbl.org zone (you can test with 2.0.0.127.multi.surbl.org which should return a hit and 1.0.0.127.multi.surbl.org which should not).

I think ISP DNS servers may do this only for root domain names, e.g. "nonexistent.com", but not for "subdomain.existent.com", because in those cases the information comes from the authoritative nameservers of existent.com.

Back in 2003 Verisign tried this DNS hijacking with the .com/.net TLD and they failed big time. I am disappointed to hear ISPs started doing this again.

Reply
by Peter Karsai (ORF Team) more than 10 years ago
(in reply to this post)

7

@Peter Karsai (ORF Team): Thanks for the info. It does make sense what you're saying and it seems pointless to me. I've been using a local DNS with somewhat success but I will try the 2 IPs you suggest and see how it works.
Thanks for the help!

Reply
by Aaron more than 10 years ago
(in reply to this post)

8

@Peter Karsai (ORF Team): Hi Peter. Its the same thing Verisign was doing back then. Unfortunately, the ISP's DNS servers seemingly answer for absolutely anything. I just tested with my own cable ISP, Cox Communications, and it always answers with the same IP for non existant domains or subdomains. These ISP's have it setup to never return an NXDOMAIN. Its been the cause of major controversy. Most of them reluctantly did setup "clean" DNS servers that don't do this and you can "opt out" either by manually entering the IPs of these clean DNS servers or sometimes they setup an option on the account management page which I guess triggers their DHCP server to send you the good DNS servers upon lease renewal.

Reply
by Bill Roland more than 10 years ago
(in reply to this post)

9

@Bill Roland: That is indeed a very unfortunate practice (but I could have really used harder words here). In any case, this is one of the reasons why our best practices document recommends using a local DNS server for ORF - it is always a lot more reliable. Sure, even a local DNS server could be a problem if it has the ISP DNS servers configured as forwarders, so going to the root servers is the best.

Reply
by Peter Karsai (ORF Team) more than 10 years ago
(in reply to this post)

New comment

Fill in the form below to add a new comment. All fields are required. If you are a registered user on our site, please sign in first.

It will not be published.
hnp1 | hnp2