Link to home
Start Free TrialLog in
Avatar of deepslalli
deepslalliFlag for United Kingdom of Great Britain and Northern Ireland

asked on

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
Avatar of markpalinux
markpalinux
Flag of United States of America image

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?
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.
Avatar of deepslalli

ASKER

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
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.
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
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.
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
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?
ASKER CERTIFIED SOLUTION
Avatar of Simon Butler (Sembee)
Simon Butler (Sembee)
Flag of United Kingdom of Great Britain and Northern Ireland image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial