How IT Works Domain Name System

Regis Donovan

Without DNS, the Internet would be an ugly place. DNS is one of the services responsible for directing network traffic based on name and numerical IP addresses. Specifically, it's the service that allows users to type in names instead of numbers to locate a Web site or Internet resource. To provide this service, DNS creates a mapping between the numeric IP addresses and the human-readable domain names that Internet users are accustomed to using and can remember more easily.

As you know, hosts connected to the Internet are each assigned a unique 32-bit IP address, usually expressed in a dotted decimal notation of four 8-bit numbers, such as 127.0.1.25. DNS is distributed and hierarchical; its information is spread among thousands of servers all over the world. Any one of these servers may be considered authoritative for some specified section of the DNS database, but it may need to get information about other parts of the database from other servers.

What this means in practice is that your local name server doesn't have all the information for, say, www.technetmagazine.com, but it can figure out who to ask about it and find out for you when you make a request.

How DNS Is Organized

At the top of the DNS hierarchy are 13 root name servers, which contain name server information for all of the generic top-level domains such as .com and .org as well as country-specific DNS addresses such as .uk or .nz. The name servers for each of these top-level domains contains name server information for domains within that top-level domain. So the name server for .com will contain information about microsoft.com but will not contain information about microsoft.co.uk. Your name server will have to contact the server that contains the information for .co.uk.

The hierarchy goes from the least specific top-level domain to the most specific hostname (see Figure 1).

Figure 1 DNS Hierarchy

All DNS records actually end with the period character (.) which represents the root of the DNS hierarchy, but it's rarely printed and is usually just assumed. A domain name that includes the trailing period character is said to be a Fully Qualified Domain Name (FQDN). However, domain names where the period character is implicit are also commonly referred to as FQDNs.

The hierarchy begins with the base of '.' and becomes more specific moving from right to left. Figure 2 explains it and compares it to a phone number.

Figure 2 A Phone Number in the Hierarchy

Just as you shouldn't expect that the phone number (212) 555-1234 will lead to the same place as(425) 555-1234, you should not expect that the URLs www.example.com and www.example. org will be the same. You shouldn't even expect that fire.ice.example.com and fire.light.example.com will be the same machine—just as you wouldn't expect the telephone numbers (710) 555-1234 and (800) 707-1234 to ring on the same phone. There are billions of pieces of information spread out in tens of millions of domains, all stored in thousands, if not millions of DNS servers worldwide, and all of this information is stored in zone files.

Data Stored in Zone Files

A DNS server that is authoritative for a given domain has a zone file that either contains all the information for that domain, or contains some information for that zone along with pointers for where to find information for subdomains within that domain. The name server that is authoritative for, let's say, example.com might have all of the information for all of the hosts whose names just end in example.com and pointers to the name servers that are authoritative for office1.example.com and office2.example.com. This kind of delegation allows for the decentralization of DNS data so that local changes can be easily made at the local level.

Information stored on a server not considered by servers higher up in the hierarchy to be authoritative for the zone in question will likely never be seen by other hosts on the Internet. If the .com servers don't list my server as a name server for the example.com domain, then no hosts on the Internet will know to ask my server for information about example.com. Any time you register a new domain, or move a domain's name servers from one set of hosts to another, you have to work with your domain name registrar to make sure that DNS servers on the Internet will know to ask your DNS server for information about your domain.

When a DNS server learns a new piece of information as the result of a query for a client machine, it will cache that information for a while—the actual cache time is specified by the server that provided the authoritative information. During that time, client machines that ask for that particular piece of information will be given the cached information; the DNS server will perform no further queries to find out if the information has changed until it deletes the cached entry when the time to live (TTL) expires or the entire cache is cleared.

Setting Up a Windows DNS Server

On Windows Server™ 2003, DNS server installation is available through the Windows® Components Wizard in Components | Networking Services | Detail | Subcomponents | Domain Name System. DNS Server software is automatically installed as part of Active Directory® setup. This can also be done through the Configure Your Server wizard.

Once the DNS server software has been properly installed, you can configure the DNS service on that host from within the DNS service console section of the Microsoft® Management Console (MMC) or using the dnscmd.exe command-line utility. To manage the DNS server, use the Connect to the DNS server dialog to connect to the DNS server in question, which is either the local machine or a remote machine that you specify on your network.

A caching-only server does not require any DNS zones to be configured or loaded because it does not have any information that is served to the rest of the Internet. It is wise to check that the root server hints file is up to date before deploying the server into production, however; this information, stored in systemroot\system32\dns\cache.dns, contains pointers to the root DNS servers where your server will begin all queries in the absence of other, more specific information. As of this writing, the authoritative location for the root hints file is ftp://ftp.rs.internic.net/domain/named.cache.

Setting Up a DNS Zone

To configure a secondary zone while using the MMC to manage the DNS server, select Action | New Zone, and select secondary when prompted for the zone type. Enter the zone name and IP address of the primary server when prompted. Note that if the primary server is not set up to accept zone transfers from this server or if the zone transfer traffic (TCP port 53) is blocked by network filters or firewalls, your server may not be able to successfully provide authoritative DNS service for the configured zone.

Primary, Secondary, Caching Servers

DNS servers that are not authoritative for any domain but which provide DNS service to client machines are called caching-only servers. They are the simplest type of DNS servers to configure. The DNS servers that store the authoritative information about one or more domains in zone files are more complicated to configure. These servers are broken down into two groups: primary servers and secondary servers.

You can set up the server to be either a primary or secondary server for a given zone. The primary server is the authoritative source for the information in a zone; any changes made to a zone must be made on the primary server. A zone must have a primary server.

A secondary server is listed as being authoritative for a given zone, but whereas the primary server has the zone file stored locally, the secondary server pulls the zone information from the primary server upon startup and whenever the information on the primary server has changed. Thus the keeper of the changes is the primary server. A zone may have from one to several secondary servers. Hosts on the Internet performing name lookup for a zone will generally try the first DNS server listed for a given zone. Most DNS server software will round-robin to rotate through a given set of records as a way to achieve some primitive load balancing.

Figure A Primary/Secondary Servers

When the Refresh timer for a zone expires, the secondary server checks for new information by comparing the serial number of the current zone on the primary server to the serial number it has stored. Depending on the server software, the serial number may be chosen when the DNS server is first set up and incremented automatically when changes occur or the domain administrator may be responsible for updating the number manually. If the number on the primary server is numerically larger, the secondary server will initiate a zone transfer, and download the entire zone file from the primary server (see Figure A).

Under most versions of DNS server software, if the new serial number is numerically smaller than the old serial number—through integer overflow or a change in serial number format, for instance—the secondary server will fail to load the new zone file until the local cache, including secondary DNS files, is cleared.

The NOTIFY operation lets secondary servers learn of changes automatically. If a primary server is configured with a NOTIFY list of secondary DNS servers for a given zone file, it will then alert those secondary servers when there have been changes made to the zone file. The secondary servers will acknowledge the NOTIFY request and poll the primary server as it does when the TTL expires.

The difference between a secondary server and a caching server is that a caching server only queries for the specific records it needs and will discard those records when their TTL expires. A secondary server will download the zone files of the zones for which it is authoritative. A secondary server will download the entire zone rather than just the specific records a user requests, and it will keep the zone file information until it has been unable to reach the primary server for some long period of time (often a week or more). These time intervals are configured in the Start Of Authority section of the zone file on the primary server.

Almost all primary and secondary DNS servers also provide a caching service for queries about records for which they are not authoritative.

Configuring a primary server is a bit more complicated. The New Zone Wizard will prompt you for the minimum information required for a zone file, beginning with the elements of the Start Of Authority (SOA) record. The SOA record has a number of fields that specify the domain name for that zone file, the primary DNS server, the responsible person, the TTL for records in that zone file, and instructions to secondary name servers for how often to check for new information and how long to keep serving the information if the primary becomes unreachable. Figure 3 has a rundown of the fields in an SOA record.

Figure 3 Fields in an SOA Record

The Primary server should be the server where you are configuring the zone. The Responsible Person should be the e-mail address of the person or group that administers the domain. Traditionally, this has been the e-mail alias hostmaster, just as e-mail issues are traditionally directed to postmaster. Instead of an @ character, use a period, so that the e-mail address hostmaster@example.com would be entered as hostmaster.example.com.

You may be asked for an initial serial number. This can be any integer, and while some DNS administrators prefer simple numbering of zone file versions, others prefer date-based numbering such as 2004062101 for the first file edit on June 21, 2004. The DNS server treats it as an integer, regardless.

The Refresh Interval determines the interval in seconds for how often a secondary name server will poll to see if there is new data. A typical refresh interval is 15 minutes (or 900 seconds).

If a secondary name server was unsuccessful in its attempt to poll the primary server to see if it should perform a zone transfer to get a new copy of a zone file from the primary server, the Retry Interval for a zone indicates how long the secondary server should wait to attempt another zone transfer. This should be shorter than the Refresh Interval; the default is 10 minutes (600 seconds).

If a secondary name server continues to be unable to communicate with the primary server, it should eventually stop responding because the zone file data it has is no longer reliable. This happens when the Expire time interval has elapsed. This is typically 24 hours (86,400 seconds) but may be set to be longer. If your primary name server is going to be unavailable for longer than the usual expire time, make sure to increase the expire time so that the secondary servers will keep serving DNS data in the interval.

The TTL tells caching servers how long to keep the information they receive as the result of client queries. The default for this is one hour (3600 seconds). If you make a change to your DNS, you should expect that most DNS servers on the Internet, and thus most users, will be receiving the new information after the TTL interval has passed and all caching servers should be reporting the updated data. There is no reliable way to issue a NOTIFY to caching servers to push changed data to the general Internet population.

If you were to look at your DNS zone file as a text file, the SOA record would look something like Figure 4.

Figure 4 DNS Zone as Text File

@   IN  SOA     ns1.example.com.  hostmaster.example.com. (
                               1            ; serial number
                               3600         ; refresh   [1h]
                               600          ; retry     [10m]
                               86400        ; expire    [1d]
                               3600 )       ; min TTL   [1h]

The @ character is a zone file variable that stands in for the fully qualified domain name for which that the zone file is authoritative. If this was the zone file for the domain name example.com, you could replace it with example.com anywhere the @ appeared in the file.

The "IN" indicates that these are Internet records. DNS was developed to work with a number of types of addresses, but is now almost exclusively used for Internet addresses. The "SOA" indicates that this is an SOA record. Every domain's zone file must have one and only one SOA record.

The other requirement for a zone file to be functional is a resource record listing at least one name server for the domain. In a text zone file, this record would look like the following:

example.com.  IN  NS  ns1.example.com. 

This code defines ns1.example.com as a name server (NS) for example.com. There also must be a resource record that lists the address associated with the name ns1.example.com. If the IP address of ns1.example.com was 10.1.2.3, the A record would look like this:

ns1.example.com. IN NS 10.1.2.3. 

All authoritative name servers for a given domain, even if they are not themselves members of the domain, need to have NS records listed in the zone file.

The rest of the DNS zone file is made up of resource records. There are several different kinds of resource records, each of which defines a different attribute for a given host. The most common is A, the address record which creates a link between a given hostname and an IP address.

The MX record designates a Mail Exchange host for a given domain. The resource record specifies the domain to which the MX record applies, the priority of this MX server, and the server to which mail should be sent. The priority allows you to set up primary and backup mail servers, and the host with the lowest priority is considered the primary mail server. If the primary mail server is unavailable, the host sending mail should attempt to send the mail via the host with the next lowest priority, and so on.

If you want to create a nickname for an already established machine, the CNAME resource record will allow you to do so. For example, you could define a name like fas.example.edu to point to the longer name faculty-of-arts.example.edu. like so:

faculty-of-arts.example.edu.  
IN   A  10.1.1.2 fas.example.edu.  
IN  A  faculty-of-arts.example.edu.

Another common use of CNAME records is to create multiple names pointing to a single multi-purpose host, like mail.example.com and ftp.example.com.

In production, one common use of CNAME records is to make it easier to maintain a set of hostnames that all lead to a single machine. This allows the hostmaster to make one change to the record of the host that the CNAMEs lead to and have this change the records for all of the hostnames. A limitation of a CNAME record is that it should not be used for a record that already has other entries. If you want your Web server, www.example.com, to point to the same machine as example.com, you cannot have a record that points example.com to www.example.com, since example.com already has other resource records such as NS and SOA records. One way to think about why this won't work is to consider that there is no way for DNS to know if you mean the host example.com or everything ending in example.com.

So while this is okay,

www.example.com.  IN  CNAME  example.com. 

this is not:

example.com.      IN  CNAME  www.example.com.

If you do want everything ending in a given domain to go to a specific host, you can use a wildcard record: a CNAME of * within that domain that points to the host to which all names that are not already defined should point. With the following record in place, any hostname that is not explicitly defined will be treated as a CNAME for wildhost.example.com:

*.example.com.    IN  CNAME  wildhost.example.com.

While this can be convenient, it does run the risk of making hostnames like example-is-a-bunch-of-idiots.example.com return a valid response.

In all the examples so far, we've seen fully qualified domain names. If a resource record does not use a FQDN, DNS assumes that the zone name should be appended. So in this case,

foo.example.com.  IN  A  10.128.5.22 

is equivalent to:

foo               IN  A  10.128.5.22

If you leave off the trailing period in a FQDN, DNS will still assume that the zone name should be appended. So that

foo.example.com   IN  A  10.128.5.22 

will create a resource record defining the IP address of foo.example.com.example.com as 10.128.5.22.

The Other Side of DNS

Where to Learn More

While this article has provided information about DNS in general as well as the Windows DNS server, there are many useful Web resources with information about DNS. The MSDN list of DNS standards documents is available at DNS Standards Documents. Information on DNS in Windows 2000 is available at Domain Name System (DNS) Center. Information on the Windows Server 2003 implementation of DNS can be found at Deploying DNS.

For more generic information about DNS, such as DNS standards and software as well as other implementations of DNS server software, the DNS Resources Directory is available at www.dns.net/dnsrd.

The Domain Name System has two major branches. The part we've discussed so far creates a mapping of names to IP addresses; the other creates a mapping of IP addresses to names. The latter is done by means of PTR (or Pointer) records. The domain in-addr.arpa holds all IP address to name mappings.

The PTR record links an IP address with a name, and it lists the four octets of the IP address in reverse and appends the PTR domain of .IN-ADDR.ARPA. A PTR record linking 10.128.5.22 to foo.example.com would be:

22.5.128.10.IN-ADDR.ARPA.  IN  PTR  foo.example.com.

If you have a small Internet presence, it's possible that your ISP may maintain the reverse DNS records. As long as the reverse zone is delegated to you, you can create a reverse zone, as PTR zones are called, and then manage your own IP address-to-name data locally.

Some hosts, particularly hosts that receive mail, will check that a forward and reverse lookup for a given host have matching records. If they do not match, the host will refuse to accept mail. It's worthwhile to verify that your mail servers have matching forward and reverse DNS information.

DNS problems can be difficult to troubleshoot. One way to approach troubleshooting is to perform lookups against a remote DNS server to make sure that machines out on the Internet are looking to the right servers and getting the correct information for your DNS zones.

Regis Donovan has worked in the IT field for over 10 years; including 5 years at Microsoft. For most of her time in IT, she has supported enterprise-wide DNS infrastructures. She is currently employed by Upromise.com.

© 2008 Microsoft Corporation and CMP Media, LLC. All rights reserved; reproduction in part or in whole without permission is prohibited.