Build a great reporting interface using Splunk, one of the leaders in the Security Information and Event Management (SIEM) field, linking the collected Windows events to www.eventid.net. The EventId.Net for Splunk Add-on assumes that Splunk is collecting information from Windows servers and workstation via the Splunk Universal Forwarder.
SMTP could not connect to the DNS server <ip adress>. The protocol used was 'UDP'. It may be down or inaccessible.
|English: Request a translation of the event description in plain English.|
|Concepts to understand:|
What is the role of a DNS server?
This was recorded after our colocation ISP changed the DNS servers (without notifying us!). Once the new DNS servers where configured into the TCP/IP stack, the errors were gone.
Checking the system for connectivity problems is a start. I used the recommendations in article ME314067 to verify that I have good domain connectivity (our server passed, but the warnings persisted). An additional command line utility to test connectivity to remote SMTP servers is described in article ME321045 (we had good connectivity). Check to ensure that EDNS is supported by the router firmware, or disable EDNS on servers that have to communicate externally. See ME832223.
I have resolved this by adding my ISP’s name server to the SMTP virtual server. If running Exchange 2003 you might need to configure your external DNS servers: In exchange system manager -> administrative groups -> first administrative group -> servers -> servername -> protocols -> SMTP -> default virtual server properties -> Deliver tab -> Advanced button -> Configure external DNS servers. In my case I entered the IP addresses of my ISP DNS server.
From a newsgroup post: "The SMTP service logs this event on 3 consecutive failures to connect successfully to the DNS server. I would suggest you check for packet loss in your network".
From a newsgroup post: "Check your firewall to see if UDP and TCP port 53 are open between the SMTP server and the DNS server. DNS queries are usually, but not always, sent on UDP port 53. Some programs send them on TCP port 53". To investigate DNS issues, use the DNS Resolver tool (DNSDiag.exe) from the Exchange Server All-In-One tools. See ME832281 and the links to "How to use the DNS Resolver to verify DNS configuration" and "Exchange Server All-In-One Tools" for information on this tool.
This error appeared for me on a Windows 2003 Server with Exchange 2003 installed.
1. I think I have at least found the reasons for these errors (SMTP 2012 & 2013) and here is how I fixed them completely. The errors seem to be caused by excessive UDP traffic to the DNS server (internal in most cases) due to a large number of NDR messages waiting to be sent from the exchange queue.
2. It appears the errors are coming from getting DNS info for NDR records (non delivery reports). Each time a spam is sent to your server to an unknown address the server swallows the message and then attempts to send the original sender back a message saying no such person exists.
3. Look under “C:\Program Files\Exchsrvr\Mailroot\vsi1\Queue” and you will probably see thousands of messages waiting to be sent out of the queue. Unless you have a very busy server or a low bandwidth internet connection, all messages that are in the queue are trying to be delivered to a server that does not exist (fake FROM addresses from spammers). You can open these with Outlook express and see they are just NDR reports being sent back to e-mail spammers informing them that the user does not exist on the server. The reason these are in the queue is because the server cannot deliver the messages because there are no servers at these fake spammer FROM addresses.
4. So I think the exchange server is creating too much UDP traffic to the DNS to get these NDR reports delivered (these errors in most cases are thereby harmless). The NDR reports cannot be delivered because spammers use fake FROM addresses so your server attempts to send these for up to 48 hours and then gives up and erases them. So much spam continues day after day to be sent to unknown users that this queue just keeps staying at a very large size. Below is how you get Exchange to not accept messages for users that do not exist on your domains. This will reduce traffic on your server and eliminate your SMTP errors on your server.
5. Exchange by default produces a NDR report for every e-mail sent to an incorrect address. For example is if a person sends an e-mail to email@example.com then the server actually takes the message sees that it cannot be delivered then sends an NDR (non delivery report) to the senders FROM address telling them that the e-mail address does not exist. Side affect of my fix below is that if a spammer is actually using a legitimate server he could check all known common names on your server and figure out some addresses that actually exist on your server. This is the fix I used to resolve the problem:
a. Load exchange system manager and then click the + on Global Settings.
b. Right click on Delivery options and choose Properties.
c. Click on the tab for "Recipient Filtering".
d. I checked the box for "filter recipients that are not in the directory". Once this box is checked the server gives you a message that you still have to make another setting to complete the process as described in next step.
e. As a final setting you have to go to the SMTP Virtual Server (also in the exchange system manager under the server) right click on the SMTP virtual server and choose Properties. Now go to Advanced for the IP address and click EDIT for the IP address (usually unassigned) and you will see a check box that says "Apply Recipient Filter". Check that box.
f. Now this will stop the exchange server from taking a message to a user that does not exist on your domains (active directory in this case) and sending NDR reports back to the spammers reducing traffic on the server.
You can also delete all the messages currently in your Exchange queue by stopping the SMTP server, deleting all the files under “C:\Program Files\Exchsrvr\Mailroot\vsi1\Queue” and restart the SMTP service. Remember these messages are not delivered because the addresses they are being sent to do not exist (unless you have an extremely busy server and very low bandwidth in which case you better open some of them and verify they are all junk). This fix resolved the problem for me.
|Private comment: Subscribers only. See example of private comment|
|Links: How to use the DNS Resolver to verify DNS configuration, Exchange Server All-In-One Tools|
|Search: Google - Bing - Microsoft - Yahoo - EventID.Net Queue (0) - More links...|
|Custom search for *****: Google - Bing - Microsoft - Yahoo|
Send comments or solutions
- Notify me when updated