OpenDNS and EMail-Delivery Problems
We have encountered a strange problem sending email to @comcast.net users at several sites running Microsoft Exchange and OpenDNS. No SMTP errors were seen in the logs other than that the emails will stay in the queue and time out and generate a basic NDR - unable to contact server message.
What was happening was that in each case the nameservers for OpenDNS wer configured inside the Active Directory as DNS forwarders. In addition the Portal classification in the OpenDNS Web interface was blocked. Comcast.net was classified in the OpenDNS database as a portal site. Because the Exchange server was using the AD DNS servers, it was getting back the OpenDNS blocked website A record (MX records were correct though) when it attempted to lookup DNS info for comcast.net.
10.211.221.33 was the AD DNS server / Domain controller:
dig +short mx comcast.net. @10.211.221.33
5 mx2b.comcast.net.
5 mx4.comcast.net.
5 mx1.comcast.net.
5 mx2.comcast.net.
5 mx1a.comcast.net.
5 mx1b.comcast.net.
5 mx3.comcast.net.
5 mx2a.comcast.net.
dig +short mx1.comcast.net. @10.211.221.33
67.215.65.130
dig +short -x 67.215.65.130
hit-adult.opendns.com.
Thus, any emails sent to @comcast.net were failing as hit-adult.opendns.com. is of course not running a mail server that will relay for comcast,net email addresses.
Options to fix this issue:
Option A.
Whitelist comcast.net in the OpenDNS interface. This works, but the problem is that other sites may fall into this same trap and require manual whitelisting.
Option B.
Exchange's SMTP connector can be configured with its own private set of DNS servers. Changing these to be 8.8.8.8 (google for example) and 8.8.4.4 would allow mail flow to use NON-OpenDNS filtered DNS resolution. Using an external facing ISP DNS server or sgw firewall appliance on the DMZ that handles public DNS would also have worked. Generally I dont like to point my servers at DNS servers that I dont have full control over, so putting a chroot bind9, unbound, or maradns cache on an sgw box would of course been my first choice.
Option C.
Smarthost the Email traffic on the Exchange server to an sgw box running postfix. This has the same effect as Option B - the sgw box will of course have its own DNS resolution that does NOT use OpenDNS - i.e. a local bind9, unbound, or maradns dns cache that it uses. The other HUGE advantage that this option provides is that the postfix MTA message logging is much more useful (in my opinion) than the odd mail/message logging that Exchange attempts to do. I find it difficult if not impossible to extract information from Exchange logs so having the smarthost on a postfix platform means that future mail delivery problems should be much easier to troubleshoot.
Option D.
Take OpenDNS forwarders off the AD servers. Let them resolve DNS names via the standard root hints that come with AD DNS. Setup an windows policy so that all members of the PROXY_USERS group (name this group whatever you like) are forced to use the proxy
server on tcp port 8080. You then just need to configure the sgw box with an instance of squid proxy, and inside the squid.conf file point the squid cache at the OpenDNS servers. This has the added benefit of adding a cache to your network which can speed up browsing (squid is faster and better at finding websites than Windows PCs) and reduce bandwidth usage.
Its also possible to combine options C and D together, however be careful that you do not re-create the same problem on the sgw box that you had on the Windows DNS. If you install a local DNS cache and then point that DNS cache at OpenDNS to reduce the load on their DNS servers and boost response times for your web users you have to make sure that the postfix MTA process is NOT using the local DNS cache since that will be OpenDNS filtered.
Setting up 2 local DNS caches, 1 for mail and 1 for filtered web browsing is of course possible but you will need 2 ip addresses to bind the 2 different DNS servers instances to in order for this to work.