I came across an interesting problem today. I have a client with three sites, all connected by VPN, each with their own Active Directory forests connected via Trust Relationships. All servers deliver mail to each others Hub Transport servers through internal IPs and host names across the VPN, external SMTP delivery is locked down pretty tight.
Everything was working well until yesterday, when users from Site B could not send emails to Site A, the NDR was a 5.5.0 No unauthenticated relaying permitted. The weird thing is that it came from some unknown mail server. IP lookup showed some east coast company, this client doesn't have any east coast locations.
After a little checking, it turns out that IP is their public web server, hosted by a company on the east coast. So why was internal mail being routed to the public web server?
The answer was DNS. Their public DNS has a wildcard record which resolves any unknown host name to the web site, which is a pretty standard configuration. The VPN between Sites A and B must have been down, causing mail-server.internal.site-a.com to resolve to their web site's address via public DNS.
Now I remember when I had setup the mail routing between sites, there was a conditional forwarder already configured on Site B's DNS server for internal.site-a.com. That's fine, I usually add secondary DNS instead but the end result is the same so I just left it alone.
Turns out, conditional forwarders don't work when the VPN is down because the remote DNS server is inaccessible and it falls back on public DNS, which led to this chain of events. The solution was to delete the conditional forwarders and add internal.site-a.com to Site B's DNS as a secondary domain. In the event of another VPN outage, the remote server will still resolve to the correct internal IP and mail will just queue up until the VPN is up again.
So if you ever have the option to setup conditional forwarders or secondary DNS and aren't sure which one to choose, I would go with secondary DNS since it still resolves the correct addresses when site links are down.
Wednesday, February 6, 2013
Subscribe to:
Posts (Atom)