DNS issues with Server 2008 RSS Back to forum
Here are some log entries. How do I deal with these System Messages to correct the behavior and actually block the spam?
----------------------------------------------------------------
Version: 4.4 REGISTERED
Log Mode: Verbose
Server: (REMOVED)
Source:
Time: 7/26/2010 12:30:27 PM
Class: System Message
Severity: Warning
Filtering Point: Non-filtering
HELO/EHLO Domain:
Related IP:
Message ID:
Sender:
Recipient(s):
Subject:
Message:
Because of problems with using DNS server (REMOVED), subsequent lookups will be performed using DNS server (REMOVED)
----------------------------------------------------------------
Version: 4.4 REGISTERED
Log Mode: Verbose
Server: (REMOVED)
Source: SMTPSVC-1
Time: 7/26/2010 12:30:27 PM
Class: System Message
Severity: Warning
Filtering Point: Before Arrival
HELO/EHLO Domain:
Related IP: (REMOVED)
Message ID:
Sender: (REMOVED)
Recipient(s): (REMOVED)
Subject:
Message:
DNS error. Test: "RDNS/PTR", server: "(REMOVED)", domain: "(REMOVED)", record type: PTR, protocol: UDP. Server response: DNS server or domain failure (SERVFAIL, RCODE 2).
----------------------------------------------------------------
Version: 4.4 REGISTERED
Log Mode: Verbose
Server: (REMOVED)
Source: SMTPSVC-1
Time: 7/26/2010 11:56:33 AM
Class: System Message
Severity: Warning
Filtering Point: On Arrival
HELO/EHLO Domain:
Related IP: (REMOVED)
Message ID:
Sender: (REMOVED)
Recipient(s): (REMOVED)
Subject: Don't feel guilty about dessert.
Message:
DNS error. Test: "SURBL: UB-BLACK", server: "(REMOVED)", domain: "(REMOVED)", record type: A, protocol: UDP. DNS timeout error.
----------------------------------------------------------------
@Lisa Hubbard:
"SERVFAIL, RCODE 2" messages are considered normal for the SPF and PTR (RDNS) tests: this error message means the host did not response to the DNS query. Such issues usually occur if a spammer is spoofing a legitimate domain, and the spam target servers try to query the DNS records of the spoofed domain to verify the source (i.e. whether the sender IP is authorized to send in the name of the domain). As many servers initiate multiple queries at once, the server of the spoofed domain will occasionally drop some of the connections (will not respond to some of the queries) to avoid meltdown.
As for the timeouts: these are also considered normal (e.g. if the queried DNS Blacklist or URL Blacklist fails to respond), though if you see them frequently, that could indicate a problem on your end: it is strongly recommended to use a local DNS server for the queries of ORF. For more information, please read our best practices guide at http://www.vamsoft.com/downloads/getmostguide.pdf ("Getting the DNS Settings Right" section)
@Lisa Hubbard:
"Are there any settings, customizations which need to be made on the DNS server to work with ORF 4.4?"
No customization required: ORF only needs the DNS server to be able to perform recursive lookups.
What can I do about the those Yellow System Messages to ensure that SOME action is taken on the emails? Most of them are spam, are they getting through, what's happening to them after the System Message is generated?
I already have about 500 today, my DNS server is local, and I'm getting super frustrated about what to do because people are complaining.
Why do I keep getting this type of message, can it be any more specific as to the problem with the DNS server, so that I can fix it? This is the local server I'm removing the backup DNS until I figure out how to fix these issues. This warning is pretty vague.
----------------------------------------------------------------
Version: 4.4 REGISTERED
Log Mode: Verbose
Server: mail2.GSGARCHITECTURE.LOCAL
Source:
Time: 7/27/2010 10:13:57 AM
Class: System Message
Severity: Warning
Filtering Point: Non-filtering
HELO/EHLO Domain:
Related IP:
Message ID:
Sender:
Recipient(s):
Subject:
Message:
Because of problems with using DNS server 192.168.1.223, subsequent lookups will be performed using DNS server 208.67.220.220
----------------------------------------------------------------
By the way, here is the DNS test from ORF:
** DNS test starting: 7/27/2010 10:58:13 AM.
Running test #1.
DNS server: 192.168.1.223
DNS transport: UDP
Domain: vamsoft.com
Status: PASSED. Record found.
Running test #2.
DNS server: 192.168.1.223
DNS transport: UDP
Domain: www.vamsoft.com
Status: PASSED. Record was not found.
Running test #3.
DNS server: 192.168.1.223
DNS transport: UDP
Domain: l0b4d5f4ciucp035q0k7mcndjb5qw1lkwv.com
Status: PASSED. Domain was not found (NXDOMAIN).
Running test #4.
DNS server: 192.168.1.223
DNS transport: TCP
Domain: vamsoft.com
Status: PASSED. Record found.
Running test #5.
DNS server: 192.168.1.223
DNS transport: TCP
Domain: www.vamsoft.com
Status: PASSED. Record was not found.
Running test #6.
DNS server: 192.168.1.223
DNS transport: TCP
Domain: l0b4d5f4ciucp035q0k7mcndjb5qw1lkwv.com
Status: PASSED. Domain was not found (NXDOMAIN).
Running test #7.
DNS server: 192.168.1.124
DNS transport: UDP
Domain: vamsoft.com
Status: PASSED. Record found.
Running test #8.
DNS server: 192.168.1.124
DNS transport: UDP
Domain: www.vamsoft.com
Status: PASSED. Record was not found.
Running test #9.
DNS server: 192.168.1.124
DNS transport: UDP
Domain: l0b4d5f4ciucp035q0k7mcndjb5qw1lkwv.com
Status: PASSED. Domain was not found (NXDOMAIN).
Running test #10.
DNS server: 192.168.1.124
DNS transport: TCP
Domain: vamsoft.com
Status: PASSED. Record found.
Running test #11.
DNS server: 192.168.1.124
DNS transport: TCP
Domain: www.vamsoft.com
Status: PASSED. Record was not found.
Running test #12.
DNS server: 192.168.1.124
DNS transport: TCP
Domain: l0b4d5f4ciucp035q0k7mcndjb5qw1lkwv.com
Status: PASSED. Domain was not found (NXDOMAIN).
** DNS test finished.
Your DNS configuration appears to be OK.
@Lisa Hubbard: This list of tests shows two dns servers(.124 and .223) but the previous timeout shows instead of flipping from .223 to .124 it flipped to an OpenDNS server which should be configured as a forwarder? Perhaps you have some DNS configuration issues?
"This is the local server I'm removing the backup DNS"
Just noticed that - sorry - that explains it - don't do that. Orf will flip between the two local DNS servers whenever there is a timeout.
@Lisa Hubbard:
"What can I do about the those Yellow System Messages to ensure that SOME action is taken on the emails? Most of them are spam, are they getting through, what's happening to them after the System Message is generated? "
When a timeout occurs, ORF will skip the given test and proceeds with the rest. If you have many timeouts, the filtering efficiency will suffer, as ORF relies heavily on DNS-based tests. We do not recommend using OpenDNS servers as forwarders, as some DNS and URL blacklist refuse to reply queries coming from such servers.
@Lisa Hubbard: As mikeg pointed out, this indicates ORF fell back to the other DNS server configured, as the first timed out a lot.
@Krisztian Fekete (Vamsoft):
I use OpenDNS as a forwarder and about a year ago had to quit using uribl.com blacklist for an url blacklist option because they quit answering queries from OpenDNS. Now I only get about 20 timeouts per day from Barracuda as follows:
Message:
DNS error. Test: "DNSBL: BRBL", server: "192.168.1.17", domain: "152.122.35.89.b.barracudacentral.org", record type: TXT, protocol: UDP. DNS timeout error.
I use the following:
DNSBL:Barracuda Reputation Block List, Spamhaus Zen, SpamCop Blocking List
URLBL: Combined SURBL List
@mikeg:
You might want to add the Spamhaus DBL URIBL as well, it's very reliable and effective:
http://www.vamsoft.com/spamhaus-dbl.asp
I assume if Spamhaus ZEN accepts queries from OpenDNS servers, you should not have any problem with DBL either.
Thanks - been on my list of things to do - just never risen to the top yet. Any that slip through Orf now is generally caught by Trend Micro - my second layer of defense.
I am having this same issue after upgrading to 2008 R2 hosting the DNS Server. More spam is going through to the end user.
@Jonathan:
I wonder if EDNS causes these timeout problems Lisa and you experience... EDNS is enabled by default for the first time in 2008 R2. You might try disabling EDNS probes by issuing the following command:
dnscmd /config /EnableEDNSProbes 0
It's just a wild guess, but may worth a try.
http://en.wikipedia.org/wiki/Extension_mechanisms_for_DNS
http://technet.microsoft.com/en-us/l.../cc787130.aspx
I still receive a lot of these type messages after disabling the EDNS probes.
Message:
DNS error. Test: "DNSBL: BRBL", server: "192.168.0.3", domain: "183.93.162.59.b.barracudacentral.org", record type: TXT, protocol: UDP. DNS timeout error.
Because of problems with using DNS server 192.168.0.3, subsequent lookups will be performed using DNS server 192.168.0.22
@Jonathan: There is another known problem with the Windows Server 2008 DNS (it may stop processing some TLDs when using root hints, unless the TTL is set suitably high, see http://support.microsoft.com/kb/968372). You may try setting MaxCacheTTL registry value to 2 days or greater as the article suggests to see if that solves the problem, though this is just another wild guess... (A customer reported problems with his Exchange server and ORF recently, and it turned out this was the cause).
I made the EDNS and TTL changes to our DNS, we'll see if it makes an improvement. Regarding Barracuda, I didn't know we had to register until recently, so that is making a big difference. But, too many bad emails are getting through as PASSED, when they are obviously SPAM. There are so many I just can't get a handle on it.
@Krisztian Fekete (ORF Team): Krisztian, thanks for replying. I only experienced this issue after upgrading to R2 and this appears to be both an 2008 and 2008 R2 issue.
@Lisa Hubbard:
Yes, Barracuda requires registration: that explains the timeouts :)
"But, too many bad emails are getting through as PASSED, when they are obviously SPAM. There are so many I just can't get a handle on it."
If configured properly (and DNS lookups can be performed without problems), ORF should catch 94-99% (or even more) of incoming spam with zero (or very minimal) false positives, see
http://www.vamsoft.com/press-release-2010-05-05.asp
and
http://blog.vamsoft.com/2010/05/20/configuration-used-for-the-vbspam-test/
If your current catch rate is below that, please describe your system setup (OS, Exchange version, perimeter and back-end servers, secondary MXs, through which hosts the emails are relayed in, other filtering software which may affect the email flow, etc.) and send us your configuration file called orfent.ini and your .log files from the past 1-2 days (so we need the file called orfee-2010-08-10.log and orfee-2010-08-09.log) to . These files are located in the ORF directory by default (Program Files \ ORF Enterprise Edition or \Program Files (x86)\ORF Enterprise Edition on 64-bit systems). Please send us raw .log files, Log Viewer exports are not suitable.
If you agree, I will review your current configuration and make some suggestions to improve the filtering efficiency.
I ran into this issue as well. I found that using openDNS as a forwarder on the DNS server that ORF points to wasnt working at all. I simply setup a separate DNS server (not attached to AD) and pointed the forwarders at the fastest DNS server I could find. To find your fastest DNS server, download http://www.grc.com/dns/benchmark.htm and then add your ISP's dns servers. You'd be surprised how often your ISP's DNS servers are slower than most public dns servers. Once you find a suitable set of DNS servers, simply add them as your forwarders on the new local DNS server as forwarders, and test to make sure recursion is working properly. If so, add this new local DNS server to ORF.
** I wouldn't recommend using the public/ISP DNS server directly through ORF. If you use a local DNS server and then forward it, you get all the advantages of caching (much better performance).
hope this makes sense..
I just said DNS way to many times..
@TR:
I have used OpenDNS as forwarders for my 2 local dns servers for years and only have occasional problems. However, since 10/7/11 there have been issues with OpenDNS and various DNSBL's that I also use. They are working on it but no resolution yet.
http://forums.opendns.com/comments.php?DiscussionID=11693&;page=1#Item_0
@mike g:
They have posted a fix at the link and I quote:
"After further research (thanks to all of you who opened tickets) we were able to identify what caused this. There was a recently change to the Suspicious Response Filtering that included the "localhost" subnets (127.0.0.0/8). So anyone who was doing RBL filtering (which commonly uses this address space for results) with Suspicious Response Filtering enabled had the results stripped and it would appear as if messages were not spam when they were.
We are reverting that change and that will be pushed to production over the next few days. In the mean time, if you are using OpenDNS and have your mailservers doing RBL filtering through OpenDNS, then you should disable the Suspicious Response Filtering option under the Security settings for your network to get RBL responses."
I can't tell if ORF is working anymore since upgrading our DNS to Server 2008. All I see are a bunch of yellow logs which say things link DNS timeout, DNS server or domain failure.
Are there any settings, customizations which need to be made on the DNS server to work with ORF 4.4?