Friday, November 20, 2009

OpenDNS interferes with Outlook Anywhere

My Problem:
In an office using OpenDNS for name resolution, Outlook Anywhere retrieves an SSL certificate from OpenDNS rather than searching for and using the SSL certificate installed on your Exchange serve.

My Solution:
Use conditional forwarding for your SMTP domain in your internal DNS server to divert DNS queries for your SMTP domain away from OpenDNS.

The Long Story:
One of my users reported seeing a certificate error after I switched my SBS 2008 machine from using root hints to OpenDNS servers. Strangely, I did not have those errors when I used my offsite laptop which was also using OpenDNS servers. To attempt to reproduce the error, I connected to the network with a VPN and changed my DNS server to point to the SBS 2008 server. Sure enough, I got a certificate error.

When I clicked "View Certificate", I saw that I was somehow picking up an OpenDNS cert.

I reasoned that the problem was due to Outlook 2007's hard-coded behavior of attempting to connect to it's list of autodiscover subdomains such as before finally settling on the domain's SRV record. Since we're using OpenDNS, the service tries to be helpful and returns a response when it sees we've requested a domain that does not exist (the IP returned for is which is an opendns IP)

Once again, I found it strange that if I use OpenDNS servers directly on my laptop I did not get that IP returned and Outlook Anywhere worked perfectly. I assumed it hadto do with the office having an OpenDNS account tied to that office IP whereas my laptop was not behind an IP address that had a OpenDNS accout. I did not create an OpenDNS account for my IP to see if the problems would suddenly start for me at home.

I logged into the office's free OpenDNS account but did not see any option to prevent a domain or subdomain from being resolved. I found it rather funny... I actually wanted OpenDNS to stop resolving DNS.

Several options presented themselves to me.

  1. Create a split DNS zone on the SBS server that made it authoritative for our public SMTP domain. This split DNS setup is fairly common, but requires you to manually maintain DNS entries that you create in your public zone in your private zone as well. Split DNS would casuse all clients in the building to receive a definitive resolution failure when requesting the
  2. Use conditional forwarders to forward queries for our domain to DNS servers other than OpenDNS's.
  3. Figure out a way to prevent Outlook from querying for the nonexistant domains.
Option 1 seemed viable, and I actually tried it half-heartedly. The added complexity scared me away from it and I ended up deleting the zone. Conditional forwarders won out after the thought of tweaking clients manually for anyone who ever used out email server from within the building made me break out in a rash.

I simply created a conditional forwarder that used our ISP's DNS servers for any query for our public domain name. That did the trick. Incidentally, I had attempted to put in the actually authoritative name servers as targets for the forwarder, but for some reason the targets would not resolve queries. Not willing to burn any more daylight on this problem, I settled for the ISP's DNS servers and all was well in the land.

P.S. I've also heard that the practice of returning helpful hints for non-resolving domain names that some ISPs do will also cause problems. I haven't had to deal with that yet and hope I never do.

No comments:

Post a Comment