Routing Group Connector: Unable to Bind to the Destination Server in DNS
Routing Group Connector: Unable to Bind to the Destination Server in DNS
Bookmark:
Question: I have two sites (Site A & Site B) each with an Exchange 2003 server on a single 2003 AD domain. Email from Site A to Site B is delivered without any problem, but email sent from Site B to Site A is held up in the RGC. Internet bound email goes to out fine from both Site A and Site B. This internal email problem just started 2 days ago.
In the Queue messages are building up in "Messages with an unreachable destination" and the routing group queue says "unable to bind to the destination server in DNS"
I am able to ping and telnet from Site A to Site B using the server name.
I can use NSLookup to resolve Site B's IP from the internal DNS server.
I do not have any DNS servers listed in the SMTP virtual server
IP settings are pointing to both internal DNS servers which have forwarders pointing to external DNS servers.
If I restart the SMTP service, the messages will go to the routing group queue for a minute, then are moved to the unreachable destination queue and the DNS error is shown on the routing group queue. Ive rebooted both email servers at Site A and Site B.
Ive recreated both the RGC and changed settings on the SMTP connector for Site B. Neither affected mail delivery. Also, please note this was working and now is currently not. I know of no changes to the email architecture in the last week.
Bookmark:
Question: I have two sites (Site A & Site B) each with an Exchange 2003 server on a single 2003 AD domain. Email from Site A to Site B is delivered without any problem, but email sent from Site B to Site A is held up in the RGC. Internet bound email goes to out fine from both Site A and Site B. This internal email problem just started 2 days ago.
In the Queue messages are building up in "Messages with an unreachable destination" and the routing group queue says "unable to bind to the destination server in DNS"
I am able to ping and telnet from Site A to Site B using the server name.
I can use NSLookup to resolve Site B's IP from the internal DNS server.
I do not have any DNS servers listed in the SMTP virtual server
IP settings are pointing to both internal DNS servers which have forwarders pointing to external DNS servers.
If I restart the SMTP service, the messages will go to the routing group queue for a minute, then are moved to the unreachable destination queue and the DNS error is shown on the routing group queue. Ive rebooted both email servers at Site A and Site B.
Ive recreated both the RGC and changed settings on the SMTP connector for Site B. Neither affected mail delivery. Also, please note this was working and now is currently not. I know of no changes to the email architecture in the last week.
Network_Data_Support
have you tried setting the ip address in the virtual server to an actual ip instead of unassigned and recreating the RGC.
So creating smtp conectors insyead og RGC does not help ???
maybe u should try this ...it is a long shot....that is if you are sure u have no DNS problem and after u tried SMTP connectors
http://support.microsoft.com/kb/325850
maybe u should try this ...it is a long shot....that is if you are sure u have no DNS problem and after u tried SMTP connectors
http://support.microsoft.com/kb/325850
ASKER
Hi Guys,
Thank you for the responses, but I activated one of my MIcrosoft Support Options and got their help. Long story short, I had changed the FQDN on my main server (bridgehead) last week to address an internet mail reverse DNS issue; DSBL.org said we needed a reverse DNS name that was resolvable so I changed FQDN from servername.mydomain.na to mail.myotherdomain.com.
Anyway, the domain showed as invalid mail.myotherdomain.com and was not resolvable insidethe Default SMTP Server Delivery properties box for the FQDN, but mail still worked fine between Site A and Site B up through Tuesday. Tuesday the server at Site B rebooted because of a massive power outage and then the above problem started to occur.
The reality is that when I changed the FQDN last week, the DNS cache was not cleared in Site B so it delivered mail to Site A as normal. When the reboot occurred, DNS was flushed and registered and could not deal with the FQDN that was not "valid" within the domain. OF course no errors showed this at all; all it said was "Unable to bind to destination server in DNS" even though both DNS and the server were reachable.
It seems silly and obvious now, but was not through the ordeal. Anyway, I changed the FQDN back to the internal name address and mail worked. I then changed it to the externally advertised server name and just created an internal DNS alias so that it was resolvable inside. I restarted IISAdmin and flushed the DNS on both servers and everyone is happy now.
Fix one problem, create another.... All is working now though. Thank you for your input.
Thank you for the responses, but I activated one of my MIcrosoft Support Options and got their help. Long story short, I had changed the FQDN on my main server (bridgehead) last week to address an internet mail reverse DNS issue; DSBL.org said we needed a reverse DNS name that was resolvable so I changed FQDN from servername.mydomain.na to mail.myotherdomain.com.
Anyway, the domain showed as invalid mail.myotherdomain.com and was not resolvable insidethe Default SMTP Server Delivery properties box for the FQDN, but mail still worked fine between Site A and Site B up through Tuesday. Tuesday the server at Site B rebooted because of a massive power outage and then the above problem started to occur.
The reality is that when I changed the FQDN last week, the DNS cache was not cleared in Site B so it delivered mail to Site A as normal. When the reboot occurred, DNS was flushed and registered and could not deal with the FQDN that was not "valid" within the domain. OF course no errors showed this at all; all it said was "Unable to bind to destination server in DNS" even though both DNS and the server were reachable.
It seems silly and obvious now, but was not through the ordeal. Anyway, I changed the FQDN back to the internal name address and mail worked. I then changed it to the externally advertised server name and just created an internal DNS alias so that it was resolvable inside. I restarted IISAdmin and flushed the DNS on both servers and everyone is happy now.
Fix one problem, create another.... All is working now though. Thank you for your input.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.