Dns query failed internal error

Resolving Exchange Server Error : DNS Lookup
Failed

Tools such as NSLOOKUP & TELNET are used to test
working of the Edge transport layer that controls inbound or outbound exchange
of emails.

Diagnosis:

The users face trouble with inbox or outbox mails getting stuck / not
getting delivered. This issue is often faced by Exchange 2007 Server version with
Edge Transport Role installed.

It is associated to mail queues associated with the edge transport layer.

Edge Transport Server Role

Resolution:

Reconfigure the DNS Setting over Edge transport layer.

Inspecting Queue
Viewer:

1.      
Open EMC on the Edge transport Server.

2.      
Navigate to toolbox->Queue Viewer.

3.      
Locate the Mail flow tools -> Queue Viewer
tool.

4.      
Check the last error column for any inbound
messages from accepted domains facing similar issues or not.

Performing
Internal and External DNS Lookups:

Internal
Lookup:

After ensuring that the DNS Servers are
properly configured, we need to test that they are performing proper DNS name
resolution or not. We use port 25 for sending SMTP or outbound mails, which in
this case is causing the issue of queue due to improper DNS name resolution.Testing the
port using NSLOOKUP tools is the optimal solution.

Using
NSLOOKUP Tool:

Before jumping into NSLOOKUP tools, we need to know about the process and why we are
doing it.

DNS records contain IP addresses and domain
names using which the name & server address is resolved. NSLOOKUP or Name Server Lookup is a
network administration command line tool used to obtain DNS records containing server and IP address information. To perform
testing of the port we use TELNET
service which is again a command line interface providing a bidirectional
interactive text-oriented communication facility using a virtual terminal
connection.

Recently I have observed that many of the users are facing the most common and irritating issue related to the email delivery. Whenever a user tries to send email an error with the message 451 “4.4.0 DNS Query Failed”. Today we will discuss the main causes of the error and possible solution.

This generally happens due to the misconfiguration or if we have booked the recipient domain. To solve the issue we have used simple steps to test and reconfigure the network.

Indication of the Error

•  If you are unable to send mail to the specific domain
• Error  451 4.4.0 DNS query Failed

Analysis of the error 4.4.0 DNS Query Failed: –

The issue is generally faced by the Exchange server with the installed Edge Transport Role due to which user faces trouble while sending emails.

Prerequisite:

First of all check is your firewall (if installed) is allowing the transport on SMTP port 25 and 53 to resolve the issue.

Inspecting the Queue Viewer:

Open EMC >> Toolbox >> Queue Viewer >> Mail Flow Tools >> Queue Viewer Tool >> Now check the last error column facing the same issue or not

Now Verify the DNS Configuration on the edge Transport Server: –

Note: –It is highly recommended to log onto the Edge Transport Server Locally and if you are accessing the server remotely with RDC6.0 then you have to use “/console” switch

Exchange Management Console (EMC) >> Edge Transport server >> Properties >> Select Internal DNS lookups and the default configuration setting should be All Available

To Fix the error 4.4.0 DNS Query Failed you have to change the network properties of the Edge Transport Server.

The steps to do the same is given below: –

At first click on the Server Configration >> Right click on the Server and select the properties >>Now select External DNS Lookup

1). Make a check on Use These DNS Server

2). Add the IP address of DNS Server

3). Now apply the setting

Now to use External DNS for the External domain, Configure Hub Transport

Select Hub Transport >> Select Send Connector >> Choose properties by right clicking on the Connector >> Select Network Tab >> Make a check on Use the External DNS Lookup settings on the transport server

Now restart the Transport Service, The mail should be successfully delivered to the domain.

Conclusion: –

The method described above will help you a lot in resolving the query 451 4.4.0 DNS Query Failed. In case if you are facing any difficulty while performing the required steps please comment we will sort out your query as soon as possible.

While working with Exchange Server, administrators always expect its smooth functioning. But out of some unrequired and undesired events like incorrect server settings, logical issues, storage issues, insufficient system resources, etc., the access to Exchange Server database gets hindered. Some Exchange Server errors are frequently encountered, and some are noticed at times. Exchange Server errors with event IDs 451, 452, and 471 are going to be discussed in detail (symptoms, nature, causes of errors) in this blog along with associated solutions to each error code.

To know about these Exchange Server errors, let us have a brief understanding of what causes these errors and what happens when they are encountered.

Resolving Exchange Server Error 451

To resolve the error “451 4.4.0 DNS Query Failed” displayed in Queue Viewer in Exchange, users can perform reconfiguration process or use TELNET to examine Edge transport layer working for outbound or inbound exchange of email messages.

1. The first thing you should do for fixing this error is to check Firewall and confirm transport at port 53 for DNS resolution and port 25 for SMTP.
2. Then inspect Queue Viewer by opening Exchange Management Console on Edge Transport Server. Now locate mail flow tools and select queue viewer tool.
3. Confirm DNS Configuration – To verify the DNS configuration in Exchange Server, follow the simple steps.
   1. Initially, log in to Edge Transport Server locally and use Console Switch if using the Remote Desktop connection.
   2. Open Exchange Management Console>click Edge Transport Server>select Properties.
   3. Go to Internal DNS lookups, check if it has default configuration settings. If not, set it to the default settings.
4. Performing Internal and External Lookups –
   • Internal Lookups: For multiple network adapters, users need to access Internal Network Card and select it to access card DNS setting. In the settings, you can modify all IP addresses (if not according to the required configuration).There could be a condition that there is no IP address which means NIC card is not configured with DNS server entries. To compensate for this, fill the NIC card with correct details and confirm them.
   • External Lookups: If you modify the configuration in public DNS setting for users having a single network card, it may affect external name resolution, and thus email flow might get restricted. To correct this, choose to Use this DNS option and select IP of internal DNS. Then, add host file consisting of DNS information. Finally, confirm the configuration once again.
5. Checking SMTP connection using the TELNET command
   1. Open Command Prompt by typing cmd in Windows+R. In Command Prompt, type telnet.
   2. Type set logfile (location:/filename)
   3. Now, type open mail.abc.com 25 and execute it.
   4. Now, execute the command – EHLO contoso.com.
   5. Compose a test email with email parameters like From, receive, notify, data and subject, etc.

The process terminates with a report displaying success or failure confirmation.

Resolving Exchange Server Error 452

When the insufficient resources become s sufficient enough, the submission of mails, which was stopped earlier, gets back to normal. This resuming process is called Backpressure. To avoid this situation, Exchange Server disk space should be increased to more than 4GB space.

You can resolve this error in few steps. Just follow the sequence one by one.

1. Take a backup for your Exchange database. Remove the unrequired data from the disk to have some 500 MB free space in your memory.
2. Disable Backup Pressure through the steps given below:
   1. Using the path C:Program FilesMicrosoftExchange ServerBin, locate EdgeTransport.exe.config
   2. Open this .exe with notepad and locate the add key=”EnableResourceMonitoring” value=”true”. In place of “true”, enter value – “false” and save the file.
   3. Now, start Exchange Transport services again.
3. Relocating database queue –
   Next step is changing the location or moving the queue of the database to another location. To perform this, consider the steps.
   1. Once again, open EdgeTransport.exe.config with Notepad.
   2. At the bottom, add the code – add key=”QueueDatabasePath” value=”C:QueueQueueDB”. Click Save to save this file.
   3. Now, restart Exchange Transport services to view the difference.

This method will help you to resolve the Exchange Error 452 and getting the mail flow clear.

Resolving Exchange Server Error 471

This error must be resolved in order to enable updates in the database. Otherwise, Exchange Server is unable to roll back operation and make future updates on the database. Let us find the solution for the most common error codes for the event 471 – Error 510 and Error 1022.

The main reasons for the Error 510 is spaces issues, permission issues, SAN issues causing the problem to disk reading and writing. The error 1022 occurs when disk I/O restricts Exchange to access a requested page in the database or to a check file. With disk failure due to this error, the complete access is denied for the user.

Solution for Error 510 – To resolve the error, simply troubleshoot the permissions issues, space issues, and other issues that are causing problems to the disk making it inaccessible. Once the actual reasons are found out, solve the issues by providing default or required permissions, eliminating space, and other issues.

Solution for Error 1022 – First of all, just check if the drive in which Exchange store files are stored is accessible or not. If found accessible, run the command chkdsk/f/r. If it does not fix the error, try another way. In this, check for the permissions on the Exchange folder structure. Even then, if the database is unable to mount, check for any file-level antivirus software running on Exchange Server.

Some other issues Exchange admins face

Apart from settings-related error issues, Exchange administrators may face corruption issues too. But good thing is that there are many Exchange Recovery tools to recover data from EDB files. Exchange users can directly access the lost or deleted Exchange data using Exchange Recovery tool. The software converts any type of EDB files to PST format or directly saves them to Exchange too. This third-party software ensures quick, complete and exact EDB recovery.

Final Words

Exchange administrators may face a lot of issues in the Exchange environment. They can be errors like Exchange error 451, 452, and 471 or EDB file corruption. Exchange errors 451, 452, and 471 can be solved in different ways without any external tools. But to recover data from corrupted or damaged or inaccessible EDB files instantly and flexibly, Exchange administrators should always rely on professional Exchange data recovery tools like Exchange Server.

Overview:

I’ve come across this with customers a few times now & it can be a real head scratcher. However, the resolution is actually pretty simple.

Scenario:

Customer has multiple Exchange servers in the environment, or has just installed a 2^nd Exchange server into the environment. Customer is able to send directly out & receive in from the internet just fine but is unable to send email to/through another internal Exchange server.

This issue may also manifest itself as intermittent delays in sending between internal Exchange servers.

In either scenario, messages will be seen queuing & if you run a “Get-Queue –Identity QueueID | Formal-List” you will see a “LastError” of “451 4.4.0 DNS query failed. The error was: SMTPSEND.DNS.NonExistentDomain; nonexistent domain”.

Resolution:

This issue can occur because the Properties of the Exchange Server’s NIC have an external DNS server listed in them. Removing the external DNS server/servers & leaving only internal (Microsoft DNS/Active Directory Domain Controllers in most customer environments) DNS Servers; followed by restarting the Microsoft Exchange Transport Service should resolve the issue.

Summary:

The Default Configuration of an Exchange Server is to use the local Network Adapter’s DNS settings for Transport Service lookups.

(FYI: You can alter this in Exchange 07/10 via EMS using the Set-TransportServer command or in EMC>Server Configuration>Hub Transport>Properties of Server. Or in Exchange 2013 via EMS using the Set-TransportService command or via EAC>Servers>Edit Server>DNS Lookups. Using any of these methods, you can have Exchange use a specific DNS Server.)

Because the default behavior is to use the local network adapter’s DNS settings, Exchange was finding itself using external DNS servers for name resolution. Now this seemed to work fine when it had to resolve external domains/recipients but a public DNS server would likely have no idea what your internal Exchange servers (i.e. Ex10.contoso.local) resolve to.The error we see is due to the DNS server responding, but it just not having the A record for the internal host that we require. If the DNS server you had configured didn’t exist or wasn’t reachable you would actually see slightly different behavior (like messages sitting in “Ready” status in their respective queues).

An Exchange server, or any Domain-joined server for that matter, should not have its NICs DNS settings set to an external/ISPs DNS server (even as secondary). Instead, they should be set to internal DNS servers which have all the necessary records to discover internal Exchange servers.

References

http://support.microsoft.com/kb/825036

http://technet.microsoft.com/en-us/library/bb124896(v=EXCHG.80).aspx

“The DNS server address that is configured on the IP properties should be the DNS server that is used to register Active Directory records.”

http://technet.microsoft.com/en-us/library/aa997166(v=exchg.80).aspx

http://exchangeserverpro.com/exchange-2013-manually-configure-dns-lookups/

Exchange 2013: Stuck messages in OWA’s Drafts folder and DNS