Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

My company uses an SBS 2003 server and makes use of Exchange to host our own email. We also have a linux server hosting domains for some of our clients. In order for us to send to those clients, we had internal DNS set up to shadow the client domains to provide "correct" MX records inside our network. For example, public DNS for a domain abc.com might point to 1.2.3.4, but internally we have MX records set up to route mail for abc.com to 172.16.0.4, which is the linux email server. This setup was entirely functional; this is just back story.

We've recently moved one of our client domains from our internal linux server to an external email provider. When we did that, we naturally deleted our internal shadow DNS records so our Exchange server would fetch correct (public) DNS records and route mail out to the new external host. This has NOT had any effect on Exchange though. Even after rebooting the Exchange server and completely flushing the DNS cache (nslookups on the Exchange machine itself correctly resolve to the new external address) Exchange still attempts to deliver messages for the domain to our internal server! Exchange correctly routes to all other internal and external domains when sending email.

Somehow Exchange is trying to deliver to a machine that by all accounts it has no business trying to use for just this one domain. Is there a DNS cache that Exchange uses internally? Is there a way to flush that internal cache? What else could I be missing?

share|improve this question
2  
You didn't happen to setup an SMTP connector with those client domains in the address space, did you? That's how I normally route mail between two different mail servers internally; it could be something overlooked. –  gravyface May 17 '10 at 15:05
    
No, there are only the default connectors across the board. The only other thing that occurs to me is that this SBS server was a migration from an older server. The ESM still lists the old Exchange server by name even though it doesn't exist on the network or DNS anywhere. I wonder if that's gumming things up at all. –  beporter May 17 '10 at 16:41
    
So you have done nslookup -q=mx abc.com from the Exchange server and it resolves to the correct external address? –  smoak May 17 '10 at 17:13
    
That's absolutely correct. It's the craziest thing. That's why I'm posting here: I can't figure out what's causing Exchange, and Exchange only, to continue to use the old internal DNS records to route outbound email for JUST that domain. In fact, we've moved other clients out from our internal linux server to external hosts before-- without this issue arising. –  beporter May 17 '10 at 18:46
    
Could there be an entry in your lmhosts / hosts file that points to the old IP address? –  adamo Sep 11 '11 at 11:24

1 Answer 1

To fix (or rather work around) this issue, configure an External DNS Server for your SMTP.

In Exchange System Manager:

Expand Servers -> [your server] -> Protocols -> SMTP

Select "Properties" for your SMTP virtual server and go to the Delivery tab. Click Advanced and then Configure. Now you are able to add external DNS servers to use for outbound mail routing.

I've used this a approach to remedy identical situations on both Exchange 2003 and 2007 with success

share|improve this answer
    
Ahh, that would have been an interesting thing to try. I would be curious to see what happens if I were to set this, then subsequently clear it. I can't rightly accept the answer without having tested it myself though. –  beporter Dec 29 '11 at 15:06
    
Well, there's no harm in trying, the only thing you do is ask the exchange server to perform a direct public DNS lookup, instead of having your internal DNS servers forward (or potentially answer with cached records) the request. This will only apply to outbound mail. –  Mathias R. Jessen Dec 29 '11 at 16:55

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.