DNS Setup

Many of the services we'll be setting up work best in a "domain" environment, which is why I'm going to be making my new servers Domain Controllers, among other things. A domain NAME is something like "google.com", and you can actually buy a public name like that ($10/year fee at most places), but you don't have to. If you buy a public domain name, you can not only use it to set up a domain for your computers to be managed by your servers, but also to have a website and e-mail, which are the only things most people think domains are for.

BUT!!! If you already have a website and/or e-mail solution (maybe gmail and a free blog, for instance), there's no need to actually buy a public domain address just to run your network - you can call it whatever you want, and don't even need a dot-anything at the end of the name (though many times in this case, I see people actually name the domain something like "domain.local").

Now, no matter what, when you go to create your domain, your first domain controller is going to ask the nearest DNS (Domain Name Service) server for the address of the authoratative server for that domain name - to make sure it's allowed to create that domain. One of the required bits of information when you register a domain name is the address of a name server, which is a DNS server. That DNS server holds the master records that tell other machines what address to translate your domain name to, including the address of the authoratative server. If you've purchased a domain name, it is possible to set your server as the authoratative server for that domain, meaning that anyone asking for an address in your domain will actually be getting the answers from your server, whether they're asking from a machine within your network, or somewhere out in the world. The traffic that could potentially generate might be too much for your servers which, if they're running Foundation, are pretty low-end after all.

It's far better to let your registrar's own name servers handle all the requests from the outside world. But maybe you can see the problem building up...if your servers aren't the authoratative name servers for the domain, how can you get permission to set your servers up as domain controllers? An even bigger problem is if you don't buy the public domain name - if your server starts asking other servers who is in charge of that non-existent domain name, it's not going to get any answers.

The solution for both problems is the same...you "trick" your servers. What you actually do is set your server up as a DNS server, just for handling requests within your own network, and give it it's own address as the address of the authoratative server. Finally, you tell it to use itself as it's own server to get answers from. That way, when it asks it's DNS server (itself) for the address of the authoratative server, it gets it's own address, and grants itself permission to create a domain.

I know it seems like a security risk that you can just "trick" them in this way, but it's really not. Because the only computers in the world that will be asking your server to translate domain names, are computers which are configured to use your server as their DNS server. Nobody is going to do that, of course, except the computers on your network. So even if you told your computer that it's authoratative for the domain microsoft.com and set up a domain in that name, the only computers that are going to think that your server is microsoft.com, are your own users. Everyone else will get info from the actual microsoft.com name server. The result of that would be that your users would be unable to communicate with the real microsoft.com computers (e-mail, web site, etc), but nobody else would be affected.

One final problem for those of us whose network domain uses the same domain name as your website and/or e-mail domain. As I said, all the computers in your network will be using your server to translate DNS addresses rather than the "public" nameservers contained in your domain name registration. So ironically, you end up being the only users in the world who can't get to your own website.

The answer to this one, fortunately, is easy enough: we'll just copy all the DNS records from the public nameservers for your domain onto your own server. That way, they get the same IP Address for the website-hosting computer from within your network as everyone else.

So...all the background is out of the way, so what should you do ahead of time?

1. Register your public domain name, if you want to
   • I do recommend allowing the registrar to host the public name servers
   • If you don't already have e-mail and a website, most of them also offer these services for additional fees. Again, since we're using Foundation server, I recommend out-sourcing these services rather than trying to run them from your server...it's a lot easier, too! Personally, we use the free version of Google Apps which allows up to 50 e-mail addresses/users
2. Find out how to get to your DNS listings for your domain name, as we'll need to copy these later
3. If you're not going to register a public domain name, make sure that whatever you do decide to name your domain won't block your access to someone else...call it something that will never be a website like "complanyname.local" or just plain "companyname" without a dot-anything.
4. The way I have my network set up (and the way I do recommend) is to have a router that serves as both a firewall for my network as well as a DHCP server, assigning IP addresses to any computer within my network that asks. Though you can configure your server to fulfill both these roles (if you have two network cards in your server) it does add a LOT of complexity to your setup. So make sure you've got a router that does both of these things, and that it's configured correctly. If you have multiple offices, you may want one that creates a VPN link between the offices as well...that's how mine is set up.