Active Directory design for hosted services provision

I operate a small-time hosted services[1] company as a means of paying off my student loans. I own a few Windows rackmount servers located in a datacentre. Provisioning is done by some tools I wrote in C# that tie in with WMI and ADSI to configure Active Directory, IIS, and Exchange for my clients.

[1]I probably should say "web hosting" but I provide more services than that.

It all works alright so far, but when I started I decided to use the same domain name internally as externally. "Foohost.com" is both my AD directory name, and the domain name of my company's website. The AD DNS servers are exposed.

When I expanded to two servers and established a private link between them (using the 192.168.x.x band) things started breaking as the DNS servers were returning these private IP addresses when people on the Internet tried to nslookup the addresses of my servers.

I've now read a few articles on TechNet on Active Directory design, they recommend using "internal.foohost.com" for the Active Directory domain and "foohost.com" externally. This makes sense to me, but I'm confused when it comes to setting up my DNS servers properly:

I'm using the Microsoft DNS Server that comes on Server 2008, which doesn't have support for ACLs or tigher control over recursion. The DNS server has a zone file (sometimes AD-integrated, other times using the filesystem) for each website or client's domain name. I don't know if I should use a separate, dedicated DNS server (which I can't really afford) with recursion disabled just for hosting my client's zone files, and use the AD's DNS servers strictly for the AD domain zone files, and have recursion enabled (so servers in the domain can resolve Internet DNS entries) but have it sealed off from the public by a firewall.

...which is another thing: I don't have a proper firewall in place. I'm just using Windows Firewall on all of my servers.

From serverfault David

• The best solution would of course be using separate DNS servers for your external and internal domains, so to avoid any conflict between them; but if you can't afford other servers, you'll have to stick with the ones you have.

  What about virtualization? You could easily setup VMs to host your public DNS servers (and only to do that); A Windows system with only the DNS service enable needs very little resources.

  David : Virtualization is an option, but I'm a bit tight for RAM. It seems a bit of a waste to have a whole Hyper-V instance eating a whole gigabyte of RAM just for DNS. I've got VirtualBox on my development machine, I'll be playing around with various configurations.
  From Massimo

• If you want to go down that route, first of all you need to rename your AD domain:

  http://technet.microsoft.com/en-us/library/cc786120%28WS.10%29.aspx http://technet.microsoft.com/en-us/library/cc794869%28WS.10%29.aspx

  I suggest using "foohost.local" (or "foohost.internal", "foohost.dom", "foohost.private", and so on), so to remove any dependency between internal and external domain names.

  When you succesfully complete the domain rename operation, you will then be able to properly manage a separate DNS zone for "foohost.com".

  From Massimo

• You can disable registration of certain adapters in DNS and that will solve that problem.

  Domain rename is a major ordeal and not something I would recommend. There's absolutely nothing wrong with your AD being company.com and your Internet presence being company.com. This is a VERY common setup.

  Generally you have seperate DNS that's Internet facing. Maybe look at something outsourced for your Internet facing DNS? It's relatively inexpensive and it would free you of the burden/responsibility.

  Evan Anderson : I heartily disagree with using the same DNS name for the Active Directory and the public Internet presence. It's a common practice, but that doesn't make it right. It's a configuration that causes "make work" (manually synchronizing public DNS entries in the private DNS to allow public resources to resolve via the private DNS) that provides no technial gain. It might give you a "warm fuzzy feeling" to have both AD and the public-facing presence named the same, but all it really does is cause you to have to babysit DNS in the future.

  Brian Desmond : Having worked in dozens of large orgs (think 50K - 500K users), I can only think of one of them that didn't use the same namespace for both sides. None of them had a DNS babysitter either. What you need is a process for managing your DNs and that's going to happen regarldess of what design you choose.

  Evan Anderson : You've been in larger organizations that I have (50K is my upward limit), granted. I've been in plenty of small organizations where I find hackery such as all DCs in the org. running IIS and doing HTTP redirects for "domain.com" to "www.domain.com" (which, in turn, has an "A" record in the AD DNS that must be updated every time the public address for www.domain.com changes) to see that using the same name for AD and the public site lends no advantage. Being common doesn't make it right. Using the same name for AD as for the public DNS offers no practical advantages-- it only creates work.
  From Brian Desmond

• You really should keep the DNS for Active Directory and the DNS for public resolution of your hosted domains in different DNS servers. You've already seen that the Microsoft DNS server, while fine for "behind the firewall" duty serving up the DNS for Active Directory and recursive name resolution for client computers, lacks features that you might want in an Internet DNS server (ACLs being a big one that you already mentioned).

  I don't host any DNS myself, or recommend that my Customers do so. Third-party DNS hosting is always the way I go. Having said that, if you're looking at hosting your DNS yourself for cost / control reasons, you might consider running a couple of small Linux VMs running BIND for the public DNS.

  Edit:

  There's some good discussion about domain rename here: http://techrepublic.com.com/5208-6230-0.html?forumID=102&threadID=229757&start=0

  I've done domain-rename in small environments (sub-20 PCs, 2 DC's) and in lab scenarios and had no problem with it. The experiences related in that techrepublic.com link pretty much mirror mine. If you're dealing with a small number of domain member server computers I think it's highly feasible. (Test it in a lab setting first, obviously.)

  David : Thanks for the tip. I'll go with separate DNS Servers for internal and Internet-facing. I won't be renaming my domain, the plan is to reformat my servers and start from scratch, I don't have many clients and they've all agreed to having a couple hours' downtime if it means better service in future.
  From Evan Anderson

• I would recommend using a single namespace for the domain, which all of your servers will have to use as their FQDN. Otherwise, your going to find that as you grow, you're going to have to add DCs to each domain for redundancy.

  Note that domain membership does not necessarily have to have a relationship to your applications. You can call your domain "datacenter.foo.com", and use bind to serve your external domains. By doing that, you also get the ability to manage with GPOs from place.

  Read Microsoft's documentation on these topics with a critical eye, as they generally assume that you have one big, flat network.

  From duffbeer703