DNS (the Domain Name System) is the Internet standard used
for translating the “human-friendly” host names of computers on a TCP/IP
network into their corresponding “machine-friendly” IP addresses. If you want
users to be able to use host names to connect to computers on an IP network
(for instance, by typing www.techrepublic.com
into their browser’s address window instead of the TechRepublic
web server’s public IP address), you must provide them with a DNS server that
can resolve those names.

A central DNS database holds the information about
registered top level domains (for example, .com) and public DNS servers on the Internet
direct users’ queries to the proper DNS server for a particular second level
domain (for example, techrepublic.com). Most companies maintain their own DNS
servers for their domains, making DNS a distributed database.

If your company has registered a domain name (or is planning
to do so), you have two choices: you can host your own DNS servers or have a
hosting service do it for you. If you use a web hosting company to host your
web servers, they will usually also host your DNS at no extra cost. If you
choose to set up your own DNS servers, you need to register them with your
domain registrar so they can point your domains to your servers.

Tips in your inbox

TechRepublic’s free Strategies that Scale newsletter, delivered each Tuesday, covers topics such as how to structure purchasing, when to outsource, negotiating software licensing or SLAs, and budgeting for growth.

Automatically sign up today!

Even if you don’t make any servers available to the
Internet, you still need DNS if your internal network is a Windows 2000 or
later domain. Windows Active Directory requires DNS to resolve host (computer)
names to IP addresses on the LAN.

If you’re just setting up a new network, it pays to plan ahead
for scalability as you design your DNS infrastructure.

The DNS hierarchy

The first step in creating a DNS infrastructure that will
scale with your business is to understand how DNS works. The system is
structured in a hierarchical manner, both logically and physically.

The logical hierarchy

On the logical side, the DNS namespace contains several
levels:

  • Root
    level. In a DNS address, this is represented by a dot (.)
  • Top or
    first level. This represents a domain type (such as .com, .org, .net, .edu, .mil, .gov, etc.) or a
    country (such as .uk for the United Kingdom, .it
    for Italy, .fr for France, .cn
    for China, .ru for Russia, .au for Australia,
    etc.).
  • Second
    level. This is the domain name that you can register for an annual fee
    with official registrars (accredited by ICANN) such as Network Solutions
    (the original registrar), GoDaddy.com, Joker, Tucows,
    Register.com, Dotster and many others.

Each second level domain must be unique within its top level
domain. In other words, there can be only one mydomain.com, but there can also
be a mydomain.net, mydomain.org, and so forth. Some top level domains are
restricted. For instance, only educational institutions can register in the .edu domain, only U.S. government agencies can register in
the .gov domain, etc.

NOTE

Although technically all Internet domain names end with a dot
to represent the root level of the namespace, DNS software in use today does
not require you to enter the ending dot to resolve names.

The physical hierarchy

The physical machines that contain parts of the distributed
DNS database are also structured in a hierarchical configuration:

  • DNS
    root servers have responsibility for the . (root level) domain. They contain a database of servers
    in the next level down, those that are responsible for the top level
    domains such as .com or .net.
  • The
    top level domain servers contain a database of name servers that are
    responsible for the second level domains.
  • The
    second level domain servers (such as the DNS server or servers for your
    organization’s domain) handle queries for actual DNS addresses (such as www.mydomain.com,
    where “www” is the host name of a web server) and subdomains,
    such as accounting.mydomain.com.

Here’s how this actually works: a client program, such as a
web browser, that needs to connect to another computer using a domain name (for
example, www.mydomain.com), sends the query to the DNS server that the client
computer is configured to use (for a business computer, this would probably be
one of your organization’s DNS servers; for a home computer, it might be the
ISP’s DNS server). If the address you want to resolve is in the .com top level
domain, your DNS server sends a query to the top level DNS server for .com.
That top level server has in its database the server that handles the
mydomain.com domain, so it queries the mydomain.com DNS server and asks for the
IP address for www.mydomain.com. Then your browser can use the IP address to
connect to the www.mydomain.com web server. This is all made more efficient by
the fact that the DNS servers cache the returns they get to their queries, so
that if the same name is queried again, the client’s web server doesn’t have to
go through the whole process because it already has the results of the query
for the IP address of www.mydomain.com in its cache.

NOTE

Information doesn’t stay in the cache indefinitely. After a
specified time, called the Time To Live or TTL, the
cached information is removed.

Configuring DNS for scalability

DNS information can be replicated across multiple DNS
servers using zone transfers. For fault tolerance, your network should have at
least two DNS servers configured for each DNS zone (usually a DNS domain or subdomains). One is the primary DSN server, where the
master zone file is stored. The other is the secondary DSN server, and it gets
its DNS database information from the master, or
authoritative DNS server for that zone. You can also have caching-only DNS
servers that don’t have their own database files but only cache DNS information
or forwarders that forward name queries to other DNS servers.

When you set up a DNS infrastructure for your internal
network, one big consideration is the namespace. If the DNS will be used only
for internal queries, you don’t have to register the domain name (but there are
advantages to doing so — especially if you plan to someday use the domain name
for servers that will available on the Internet).

When your business grows to the point where you want to
provide services to users over the Internet as well as those on the internal
LAN, you have several choices:

  • Use
    different domain names for your internal and external namespaces
  • Use
    an internal domain that is a subdomain of the
    external namespace
  • Use
    the same domain name for internal and external namespaces, and configure a
    split DNS infrastructure. With split DNS, you create two different zones
    for the same domain.

You can find an explanation of how split DNS works at http://www.isaserver.org/tutorials/You_Need_to_Create_a_Split_DNS.html

For scalability, you should plan your DNS namespace in a
logical hierarchy so that you can easily add new zones without adversely
affecting the extant namespace. It’s best not to extend the namespace more than
five levels below the root (Internet or internal) domain.

If your internal network crosses multiple physical
locations, the best option may be to use an internal DNS root zone that is
authoritative for all the top-level domains on the network and is isolated from
the Internet. The DNS namespace can be hosted on multiple DNS servers for
scalability. In an enterprise environment, you can create a DNS infrastructure
with multiple top level domains.

For more information about designing a DNS infrastructure
for the enterprise with Windows DNS servers, see the Microsoft TechNet web site
at http://www.microsoft.com/technet/itsolutions/wssra/raguide/NetworkServices/ignsbp_2.mspx?mfr=true