Want to protect your cyber security and still get fast solutions? Ask a secure question today.Go Premium

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 3850
  • Last Modified:

451 4.4.0 DNS query failed. SMTPSEND.DNS.NonExistendDomain

We have a problem with our transport server sending e-mail to other exchange servers in different sites within our forest.

The transport server which is trying to send the emails is a HUB/CAS exchange 2010 server

When trying to send e-mails to users in other sites the exchange server attempts to route the emails as expected vias the SMTP Relay to Remote Acrive directory site (Inter Organisational) however we continue to receive the error in the screen shot (451 4.4.0 DNS query failed. SMTPSEND.DNS.NonExistendDomain)

All the server names are in the DNS server correctly and can all be pinged and reached from the transport server without any problems.

Lastly if we ignore these errors eventually after a period of an hour or so the mails do get delivered, however as you can imagine this is not ideal.
Exchage-2010-DNS-Error.jpg
0
deepslalli
Asked:
deepslalli
  • 4
  • 3
  • 2
1 Solution
 
markpalinuxCommented:
Do your other servers have DNS IPv66 enabled and turned on?
On my Exchange servers I disable IPv6  from the Exchange servers.

does this issue happen from the remote sites to this hub?
0
 
markpalinuxCommented:
And just to note when making changes to the send/receive connectors be sure to restart the hub transportation service. I think previous versions of Exchange will tell you when you needed to restart for change - but can tell you Exchange 2010 doesn't give this warning when you modify the connectors.
0
 
deepslalliAuthor Commented:
Hiya,

We went into the properties in the network adaptor and disabled IPv6, restarted the transport service and the queue's are still the same....same error(s) as before.

Cheers,
Shaun
0
Free Backup Tool for VMware and Hyper-V

Restore full virtual machine or individual guest files from 19 common file systems directly from the backup file. Schedule VM backups with PowerShell scripts. Set desired time, lean back and let the script to notify you via email upon completion.  

 
Simon Butler (Sembee)ConsultantCommented:
First - disabling IPv6 is a very poor solution.
All Microsoft products are now designed with IPv6 being enabled. Disabling it is a waste of time. Furthermore, deselecting it in the Network Control panel doesn't actually disable it.
I would reset it back to how it was and restart the transport service.

Was this working? If so, what has changed? Exchange is very sensitive to AD. Changes there can be problematic. Have you confirmed connectivity between Exchange servers using telnet? DNS resolution?

Simon.
0
 
deepslalliAuthor Commented:
Hi Simon,

I have re-enabled the IPv6 in the network adapter and restarted the Transport service.

I confirmed that I can telnet from the server to all other Exchange servers in all other sites without any issue using both the IP and the FQDN.

It was working initially.. and I can think of two things that would of affected our Exchanges AD environment.

1. We lost an Exchange Server in another site and had to recover it from AD.

2. We built an Exchange server in the same site as the this one and then moved it to another site.

Thank you.

Shaun
0
 
Simon Butler (Sembee)ConsultantCommented:
Moving servers between sites shouldn't be a problem. I do that all the time.
The recovery server though - how exactly did you recover that server?
Has Transport been restarted on all other Exchange servers?

Simon.
0
 
deepslalliAuthor Commented:
The recovery was done using Microsoft Exchange recovery option:

Setup /m:RecoverServer

http://technet.microsoft.com/en-us/library/dd876880.aspx

The Transport service has been restarted on all other Exchange servers in the past (not today).

Kind regards,

Shaun
0
 
deepslalliAuthor Commented:
Hi,

I have more information about this issue for you. On finding this page:

http://www.the-little-things.net/blog/2012/02/29/exchange-2010-changing-an-invalid-dns-suffixed-server/

All the Exchange Servers in other sites are in their own Sub-Domains:

domain.com - This server above with above issue.
uk.domain.com - Sub-Domain
in.domain.com - Sub-Domain
de.domain.com - Sub-Domain

I came to the conclusion that it is further to do with DNS and perhaps the way the servers are showing in ADSIEdit. Now I know enough not to touch anything in ADSIEdit without being sure I know what I'm doing. It seemed that even though most of the things the Author of the above post seemed to check out (I couldn't find where the virtual directory protocol objects were hiding) like "ncacn_ip_tcp" having the correct FQDN, I made the assumption that "Something" was not providing the full FQDN to exchange and telling it to use just the NETBIOS name. Using NSLOOKUP I did some testing and found that the servers were not available via the NETBIOS name (kinda expected really bearing in mind they are in different domains) but were fully available via the FQDN. I then changed the problematic servers network adapter TCP/IP --> Advanced TCP/IP Settings --> DNS tab to also append the sub-domains DNS suffixes when doing a DNS lookup for unqualified names,

I am running tests right now but it has been working okay for the past hour. If this is the issue then I would prefer to fix it properly and understand why than just leave it as is. Any ideas?
0
 
Simon Butler (Sembee)ConsultantCommented:
This sounds like there is a problem with your DNS setup, as it shouldn't be this difficult. Multiple servers in multiple domains isn't a problem, your configuration isn't unusual. I would therefore suspect the problem is not with Exchange, but with AD.

Simon.
0

Featured Post

Independent Software Vendors: We Want Your Opinion

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

  • 4
  • 3
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now