Active Directory design for hosted services provision

Question

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.

Answer 1

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.)

Answer 2

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.

Answer 3

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".

Answer 4

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.

Answer 5

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.