Edit: This is not a question about DDOS, but a question about how to resolve a technical issue impacting only Mac clients of Outlook Anywhere.

Problem and solution are are now known, but I cannot link it here for some stupid reason of stackexchange limits. I can suggest googling : "outlook anywhere We Get to Use Commandlets" and you should find the problem and solution described at charlietree.com

Original question follows...

I'm not a Mac user, nor the Windows Admin, so forgive me if I don't have the the nomenclature correct, but I'm trying to help another admin.

We run Active Directory and Exchange 2010. The name servers for our Internet top level domain are Linux with Bind. A subdomain like ad.example.com is the domain for AD, Exchange, etc.

In an attempt to prevent the DNS service on AD from being abused with DNS reflection DDOS attack method, port 53 was blocked at the firewall. It has the effect of blocking off site users with Mac Outlook from syncing with Exchange.

Blocking port 53 seemed the only way to go because disabling recursion on the Windows DNS causes failures to access the outside world, and unlike Bind, there is no feature like views.

Are other sites finding this is a problem, or does it hint of a configuration problem?

The admin mentioned that when traced, the connection information (perhaps with autodiscovery) came back with the address like exchange.ad.example.com, while the exchange server is also known as an address like exchange.example.com. He isn't sure if there is some place in the configuration to fix that. The idea being if we can get the "ad" out of the host name, the Mac Outlook client would not need to talk to the DNS on AD.

Our Goal: to block AD's DNS servers from DDOS abuse.

Our problem: Mac Outlook clients require access to AD's DNS when off site.

  • Any users, regardless of their operating system, should be able to connect to the autodiscover service on port 443.
    – DanBig
    Jun 11, 2013 at 15:27
  • Yes, we verified autodiscover can access over the web OK while port 53 is open on the AD DNS server. Something in this process refers to exchange.ad.example.com, which requires an NS lookup with ad.example.com, the AD subdomain.
    – labradort
    Jun 11, 2013 at 15:59
  • 1
    Your internet domain's DNS zone where "autodiscover.youremaildomain.com" is hosted internally and you are blocking inbound 53 requests to it? If that's the case, I can post an answer...but trying to understand more. If autodiscover.youremaildomain.com is resolving via your Linux BIND that is open to the outside world, what does it resolve to? Is it a CNAME or an A record?
    – TheCleaner
    Jun 13, 2013 at 15:03
  • Redo first answer here... We have autodiscover.example.com which is a CNAME to exchange.example.com. I just did a dig +trace on the lookup and this never has to talk to ad.example.com. I don't think this part of the lookup is the issue with the clients needing to reach the DNS at ad.example.com
    – labradort
    Jun 13, 2013 at 16:29
  • Welcome to Server Fault. Please do not tag questions with "SOLVED" or place answers in the question. Instead, post your own answer as an Answer below, and mark them solved by clicking the outline of the tick mark so that it turns green. Aug 2, 2014 at 21:05

1 Answer 1


I'm still a little lost as to your explanation of why you are doing what you are doing with the port 53 block. Your internal DNS within your firewall should have no reason to be exposed to the internet, so you are right to block inbound port 53 to it on your firewall. Your external DNS should provide name resolution for your external (internet facing) domain name, including autodiscover.domain.com.

I think you are overly complicating things.

Exchange can be setup to handle Mac clients running Outlook 2011 easily, using the same autodiscover methods that Outlook Anywhere and smartphones use.

You'll simply setup the proper cert, make sure the internal and external URLs for Outlook Anywhere are correct, and make sure that the proper ports (80/443) are allowed through the firewall to the Exchange server, and that the authentication is setup for Outlook Anywhere.

Once you've done this, and you can confirm via test on www.testexchangeconnectivity.com that all is setup correct, then you should have no problems configuring a Mac client running Outlook at that point.

Some URLs to help you along:







  • Our AD DNS is for the subdomain ad.example.com. It does not handle the example.com zone, but can do caching server role for that. There is something in AD or Exchange answer referring to the subdomain, and so the outside client needs to talk to the DNS at ad.example.com to get an answer. The question remains, what could be in our AD/Exchange set up which is directing the client to this subdomain? When the firewall blocks port 53 on the AD DNS, Mac Outlook is unable to connect to Exchange. There is no issue like this for remote Windows clients. That must point to something.
    – labradort
    Jun 24, 2013 at 15:18
  • All I can say is that inbound DNS isn't required at all for Outlook 2011 for Mac or technically for any "Outlook Anywhere/Activesync" type client as long as your external Domain name DNS is reachable and www.testexchangeconnectivity.com responds fine to tests. What does the client config look like in Outlook 2011?
    – TheCleaner
    Jun 24, 2013 at 15:41
  • The problem and solution are described here very well - no one at stackexchange has understood the issue: charlietree.com/…
    – labradort
    Sep 5, 2013 at 12:51
  • 1
    The solution there is no different than standard setup of Outlook Anywhere. Same as the 3rd link I posted above: premnair.wordpress.com/2010/07/03/… - The difference as to why your Windows clients didn't experience this is because Outlook for Mac uses EWS to connect, the Windows Outlook clients don't. So not properly setting the EWS URLs would be an issue. Glad you got it resolved though.
    – TheCleaner
    Sep 5, 2013 at 13:04
  • BTW, I've voted to reopen the question for you.
    – TheCleaner
    Sep 5, 2013 at 13:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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