I spend a large part of my time creating and maintaining virtual machine deployments. With the type of work we do, we often have to have a complete Active Directory environment for any given project: one or more domain controllers, one or more member servers, one or more workstations. We use virtual machines to make this kind of deployment easy.
Just to keep our network routing topology simple, we usually don’t deploy these VMs on a separate TCP/IP subnet unless we have a specific reason to do so (such as developing VMs that will be passed to a client and must be fit into a specific IP and DNS address space; if the VMs are prohibitive to rebuild, then we mimic the target environment as closely as possible). Instead, we share an IP subnet. The only major caveat with this kind of deployment is to make sure that your images don’t run a DHCP server. You really don’t want to see what happens when one of your VMs starts handing out DHCP leases to your regular workstations.
When we install these test AD envrionments, we install them as stand-alone forests. Often, though, we’ll want machines in our domain to be able to easily interact with machines in the test domains. We may be testing Exchange interoperability, for example, and want to pass messages between the test envrionment and our Exchange organization. Our developers may need to access test web services or web sites from their desktops. Functional name resolution was our major roadblock. So how did we get around it?
The first way we tried to get around this issue was to distribute a HOSTS file (C:\WINDOWS\system32\drivers\etc\hosts) to everyone who needs it. This caused some minor heartache — someone always ended up with an old version, no matter how stable the envrionment was — and it wasn’t very scalable. I knew we could do better so I kept looking for alternatives.
Happily, the Windows Server 2003 DNS server includes a feature that addresses this specific issue — conditional forwarding. In short, you configure your DNS server with a list of authoritative name servers on a per-domain basis. Every time a DNS request comes in from a client, Windows Server checks to see if the domain is on this list; if so, it queries the authoritative server and returns the answer to the client. In other words, it’s a cheat sheet that tells your DNS server “if you get asked about domain X, talk to this server here instead of the root DNS servers.” This is good stuff, and Windows MVP Mitch Tulloch wrote a great introduction to it in his article DNS Conditional Forwarding in Windows Server 2003. In addition to per-domain forwarding, you can also configure Windows Server 2003 to forward requests for all zones that the server isn’t authoritative for.
Armed with this knowledge, we now have a great solution. When we deploy a new test AD forest, all I do is the following:
- I go to the name servers for the 3Sharp domain and add in a conditional forwarding entry for the new domain, pointing to the IP address of the DC for that domain.
- I go to the name server for the test domain and set the All other DNS domains forwarding entry to point to the 3Sharp nameservers.
Voila! The test domain has full DNS coverage not only of the Internet, but of our internal domain (and without me having to change the firewall settings to allow outbound DNS requests from a new server); all the machines internally can resolve the new test domain without problems. Best of all, no one has to maintain a host file. This configuration even works nicely for envrionments that are on their own subnet, as long as you can route between them.
Mark’s article points out a few caveats with conditional forwarding, so be sure to read it. As he states, stub zones could also be used to solve the same problem and should be used if the DNS servers in the test domain are going to be changing, or if performance is an issue. You can also avoid using the All other DNS domains forwarding entry on the test name servers if you wanted to create a custom root hints file. In our case, though, I like the convenience of using the same method on both sides and we don’t have to worry about the performance hit.
Two additional caveat from our experience:
- Be sure that you configure the conditional forwarding entries to match on all of your name servers. We’ve had occasional, hard-to-solve glitches in our name resolution with our test domains from time to time. What I finally realized was that I’d failed to add the conditional forwarding entries for those domains to one of our name servers, and when clients switched over to it, it had no way to know about the test domains.
- Be very proactive about cleaning old forwarder entries out of your DNS servers. If you’re like us and have a relatively high amount of turnover for your test domains, the stale entries can add up over time and hurt your DNS server performance.