What is the purpose of a domain?

Solution 1:

Imagine you are in charge of a bunch of computers. Let's also imagine that you are tired of just referring to them by their IP addresses. Let's say you've given them cool names instead. And now you would like some way for every machine on your network to be able to find each other just by using their names. So you go and setup a DNS server, which can be queried for information about these names and who they belong to.

DNS is hierarchical, so at the top (or the root of the tree) you have the root DNS servers (represented by '.'), then you have top-level domains (.org, .com, and so on), then domains, and subdomains, and so on ad infinitum. So you need to group your names into a container. This container is your domain namespace. For example let's say your domain name is middleearth and your workstation is frodo (frodo.middleearth) and your server is gandalf (gandalf.middlearth).

The big difference between an "internal domain" and an "external domain" is who is able to query your DNS server and thus learn everything there is know about your domain. If you've setup the middleearth domain because YOU and your organization just got tired of using IP addresses to refer to all your machines (see @JamesHannah answer for why this is annoying), then you DO NOT want the public/internet/world talking to your DNS server; so outside of your network no one even knows your domain "exists". Inside your network all your machines know that the mail server is gondor.middlearth and that your DNS server knows where to find it.

An "external domain" is one you want the public/internet/world learning about... like say your website. So you buy a domainname from a provider, they make the records changes (or you do it yourself if your DNS server is publically accessible), and now everyone can find your domain. If you already own example.org you can again either through whomever does your DNS services or if you provide them yourself, add a mail server called mail.example.org (using an MX record), or really anything that you want to be part of that namespace.

And as noted by sysadmin1138, this concept is part of but not at all inclusive of what makes up an Windows Active Directory Domain.

In my opinion this is really a question about DNS. I've always liked Technet's article here, but you may find it overly long. It's well worth understanding DNS as a system administrator. It's the glue that pretty much holds the internet together (well, that and perl...).

Solution 2:

Domains are handy things, since it allows you a single namespace to locate resources. Even internally, this is quite useful. Most companies only have a few externally accessible addresses and quite a few more internal ones. Using a subdomain ("winserv023.hosting-nyc-usa.example.com") under your publicly visible domain ("example.com") makes it easy to set up and not conflict with anything else out there on the internet.

Using an arbitrary root ("winserv023.companyname") has its own problems, even if it'll never ever be visible to the world. With the expected explosion in top-level-domains in coming years, it is not impossible that "companyname." could be a perfectly valid top-level domain.

DNS domains are completely different than Windows Active Directory Domains, though AD domains do use DNS for resource location. DNS domains function the same on both Linux and Windows and follow very similar terminology. Windows DNS and Linux BIND DNS have slightly different terminology usage in their documentation but they both do the same thing in the end.

Solution 3:

Assuming you understand how domains are used on the Internet, it's easiest to think of local domains as an extension of that. These days DNS is the primary means of identifying hosts on a network. All DNS entries must reside within a domain. It follows therefore that a domain is required.

As an example, all the computers on our company network have DNS entries in the company's internal domain, just as our public resources have DNS entries in our public domain.