Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I am using my domain example.orgin my firm. I can use www.example.orgto view my website. If I try from outsite my firm there is no problem, but if I try it from inside, my windows DNS servers deliverthe IPs of domain controllers.

How can I solve this? Can I prevent my DCs from registering as in my DNS and will this be a problem for my enviroment?

share|improve this question
To clarify, your internal network DNS name is, and not something like example.local? – DanBig Jul 25 '13 at 13:18
You can solve this by naming your domain correctly, it should be something like, or If that's no longer possible you're stuck. The best you can do is setup a redirect to on any DCs that also have IIS installed (a bad idea, but a lot of domain controllers are setup poorly). – Chris S Jul 25 '13 at 13:23
"Can I prevent my DCs from registering as in my DNS" - nope. "and will this be a problem for my enviroment?" - YES! – mfinni Jul 25 '13 at 13:47
up vote 18 down vote accepted

If you've named your Active Directory then you cannot prevent this. You've gone against Microsft's best practices for naming an AD and you're seeing one of the symptoms.

You have a few choices:

  1. Migrate to a properly named AD. Something like

  2. Install a web server on each DC and configure it to forward web requests for to This is dirty and shouldn't be done, but it's an option nonetheless.

  3. Train your users to go to internally.

I've blogged about AD naming best practices multiple times and link to official Microsoft sources. You should read them:

If you want the short version:

Do not create new Active Directory forests with the same name as an external DNS name. For example, if your Internet DNS URL is, you must choose a different name for your internal forest to avoid future compatibility issues. That name should be unique and unlikely for web traffic. For example:


share|improve this answer
In addition, you can setup a simple "example" CNAME in DNS ( technically) and have it point to Then you can just tell users to go to http://example. Silly of course, otherwise #3 in MDMarra's list is the only simple solution to the issue. I've been there (split-dns) and it isn't fun to deal with. – TheCleaner Jul 25 '13 at 13:36
As long as "example" isn't the NetBIOS name for your domain. If it is, I can imagine what merry hell this would play in such an environment. – mfinni Jul 25 '13 at 13:46
I will get me some information about migration to a properly name, I am just a little bit afraid of getting problems through it. The problem is with my Nagios Monitoring which I use to make sure that and is fine from external. Here i will go and find an alternative for my setup as long i have/will not migrate. Thx – Max Jul 25 '13 at 17:16
I just want to update the answer... while it was once the best practice recommendation by Microsoft, RFC supercedes it, as it interferes with zeroconf (mDNS). Also, this TechNet article recommends against it (as of 2012), especially if you are looking to integrate your AD environment with Office 365 or using Macs on your domain, as we have both happening where I work. One noted workaround would be to use a split zone, as [detailed here](… – user312212 Sep 19 '15 at 15:53
@stevenh read the article you linked to again. It echoes my answer completely. When moving to office 365 with a hybrid identity you should set the user principal name to match the primary SMTP address of each user. This is completely independent of your directory's name. My answer was valid when I posted it and it is still valid today. – MDMarra Sep 19 '15 at 17:27

If you are running Exchange on the DC, do not set up a PortProxy - it may go without saying but it will break Exchange services hosted on port 80.

I realize this post is quite old, but you can still do this without installing IIS on the DC's. On every DC, run the following command to portproxy port 80 to the external web server.

netsh interface portproxy add v4tov4 listenport=80 listenaddress={Static IP v4 address of DC) connectport=80 connectaddress={IP Address of public Web Server}
share|improve this answer
this requires the webserver to be reachable from the DC. But non the less a nice way. Then you could redirect to www. version to take the work from the DC. (Pro tipp: i think portproxy needs "ip helper" service of windows) – Max Oct 31 '14 at 8:33

So, I don't know if this evaded anyone else, but the best fix for this issue may just be getting a secondary domain with a different suffix, especially if you cannot PortProxy because of Exchange being on the DC(or because of hostheaders issues with your web host.)

ex: If the internal AD Domain is - then you should simply purchase EXAMPLE.NET for internal use.

This is the cheapest and simplest workaround for internal web access.

That worked for us.

share|improve this answer

You may solve your problem two ways, but it involves placing an HTTP server on your DCs :

You can do the redirection with an URL redirect (HTTP 301 code), IIS 7 can do that for you, or you can install a reverse proxy (Apache for Windows) and use the following code :

ProxyPass /

ProxyPassRever /

ProxyPreserveHost On

share|improve this answer
This is included in MDMarra's answer; it's item 2. – mfinni Jul 25 '13 at 15:32

Your Answer


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.