Resouce Guides / IIS / Basics

Understanding how DNS works, part 1

DNS (Domain Name Service) is one of the most basic services on the Internet. If you want to effectively set up TCP/IP on your network, you'll probably need to install a DNS server at some point. But what is DNS and how does it work?

The early Internet

The early Internet landscape was pretty barren with only a few hundred computers making up the ARPANET, the military/educational precursor to the Internet. Then, as today, each device on the network was a node, and each node needed a unique address to enable data packets to find their destinations. Anyone who has ever used IP addresses knows that it's tough enough to remember a few addresses on your local network, much less keep track of the addresses for remote systems you use often. That's where host names came into the picture.

Host names provide a more "friendly" way to name hosts, making it easier to remember host addresses. For example, when you want to get the news, you can point your browser to instead of Add a couple of hundred other addresses to your frequent site list, and you can see that host names are a lot easier on the brain than IP addresses.

But converting host names to IP addresses doesn't happen by magic. It needs some form of translation to make it happen, and the mechanism that enables that translation is the Domain Name System, or DNS.

In the early days when there were only a few hundred nodes, a single text file could easily map host names to their corresponding IP addresses. This text file, called Hosts.txt, was managed by the Standford Research Institute (SRI) and contained all of the name-to-address mappings for all nodes on the ARPANET. Operating systems (primarily UNIX at that point) use the Hosts.txt file to map host names to IP addresses. System administrators copied the Hosts.txt file from SRI to their local systems periodically to update their address maps.

As the number of nodes on the network continued to increase, using a relatively static text file to provide mapping quickly became impractical. New hosts were added so rapidly that neither SRI nor system administrators had any hope of keeping up. So, the DNS system was developed in the mid-1980s to provide a dynamic means of updating and resolving host names to their IP addresses.

Host and domain names

Each device on the Internet is called a host. Whether the host is a computer, printer, router, and so forth, as long as it has a unique IP address, it's a host. Just as the IP address identifies the host uniquely, so does the host name. For example, assume your computer's host name is rainbow. Your computer resides in the domain So, your computer's Fully Qualified Domain Name (FQDN) is The FQDN identifies the host uniquely within the DNS name space.

Domains aren't limited to a single level. Assume has two different divisions, one on the east coast and one on the west coast. The east coast domain is and the other is Sales is located on the west coast, so its domain is Mark, who works in the sales department, has a computer named mark. Its FQDN is Traffic reaches his computer through something called delegation, which I'll cover a little later.

An organization known as InterNIC was formerly responsible for managing the majority of the top-level domains in the DNS name space. InterNIC switched from being a nonprofit organization to the now for-profit Network Solutions. When it made that switch, it lost its monopoly on the name space and now there are several entities that register and maintain the DNS name space.

How DNS works

DNS essentially functions as a distributed database using a client/server relationship between clients that need name resolution (mapping host names to IP addresses) and the servers that maintain the DNS data. This distributed database structure enables the DNS name space to be both dynamic and decentralized, giving local domains control over their own portion of the DNS database while still enabling any client to access any part of the database.

At the uppermost level of the DNS name space are the root servers. The root servers manage the top level domains: .com, .net, .org, .mil, .edu, .gov, and .int. With all the domains in existence today, not to mention all the hosts in those domains, you can see why the root servers actually maintain very little information about each domain. In fact, the only data the root servers typically maintain about a domain are the name servers that are authoritative for the domain, or which have authority for the domain's records.

The authoritative name servers actually maintain the records for a domain, or in some cases delegate some of or the entire domain to other name servers. The root servers know the name servers for, for example, and within those name servers the domain is delegated to another set of name servers that manage that portion of the overall domain. In most cases, domains and their records are either managed directly by the organization owning the domain or by the ISP that provides the Internet connection for the organization.

How DNS lookup works

A DNS client uses a resolver to request resolution of a host name to an IP address. The resolver is really just a special-purpose application that's sole function is to act as an intermediary between name servers and various applications that need name resolution, such as Web browsers, e-mail applications, and so on. Here's an example: Assume you fire up your browser and direct it to connect to Your local resolver creates a DNS query and sends it to the name server(s) listed in the local computer's TCP/IP settings.

In this case, I'll assume that you're connected to the Internet through a dial-up connection to an ISP, and the ISP's name servers are specified in your computer's TCP/IP settings. The resolver sends the DNS request to the first of those name servers. The server checks its cache of previously resolved names, and in this case I'll assume that the ISP's name server has no cached results for So, that name server sends a DNS query to the root server for the .com domain. The root server responds with the addresses of the name servers that are authoritative for the domain. Your ISP's name server then builds another request for and submits it to's name server, which responds with the IP address of That information is passed back to your resolver, which passes it to your application. Suddenly,'s Web site appears in your browser, and all in a matter of a second or two.

Resolving a host name to an IP address is called forward lookup. There are actually other ways the forward lookup can happen, depending on the way the name servers involved are configured. For now, let's assume it happens as described above.

Zones, domains, and subnets

You might think there is a relationship between an IP subnet and a domain, but there is actually no correlation at all. A given domain can encompass any number of subnets, none of which have any relationship to the domain itself. In some cases, records in the domain can even point to hosts outside of the domain's subnets. For example, assume your company maintains its own name servers for its domain but outsources hosting for its Web site. The company name servers contain a record that points the name www to the hosting company's subnet, outside of those used by your company.

A name server in most cases maintains the records for a portion of the DNS name space called a zone. In many cases, the terms zone and domain seem synonymous, but they're actually not the same thing. A zone comprises all the data for a given domain except those parts of the domain that are delegated to other name servers. So, a zone is the portion of a domain hosted on a specific name server. When the entire domain resides on a single name server, then domain and zone are synonymous.

As mentioned above, a name server can be authoritative for a zone. This means the server has full information about the zone. A single name server can manage many different zones, a case in point being a hosting company that might host several hundred or even thousands of domains. The hosting company's name servers would typically manage at least one zone for each hosted domain. In addition, a name server can be authoritative for some zones and non-authoritative for others.

Zones also fall into two categories: primary master or secondary master. A primary master maintains the original records for the zone. The zone's administrator can create and modify records in the primary zone. A secondary master serves as a read-only copy of the primary (essentially a backup copy of the zone). The name server on which the secondary resides updates its copy of the records through a periodic zone transfer, the frequency of which is controlled by the zone's configuration. A given name server can maintain primary zones for some domains and secondary zones for others, so the distinction between primary and secondary is zone-related, not server-related.

DNS records

The main purpose for DNS is to map host names to IP addresses, and the data that makes that possible are stored as records in a zone file on the DNS server hosting the zone. Within each zone file (really just a text file) are resource records that define host names and other domain elements. There are several different types of resource records, each of which performs a specific function. There are a lot of resource record types to deal with. Fortunately, most installations only require a few of the more common types, including SOA, A, NS, PTR, CNAME, and MX. The SOA record indicates that the server is authoritative for the zone, and Windows 2000 automatically creates an SOA record when you create a zone. The NS records identify the name servers for the zone.

The A record, also called a host record, maps a host name to an IP address. A given host might have different host names all mapped to the same IP address. For example, a multipurpose server might map the www, FTP, and mail host names to the same IP address, since the server performs all of those functions (Web server, FTP server, and mail server). In addition, a zone might have multiple entries for the same host name, each mapped to a different IP address. The server returns all matching addresses to the resolver. When the client is on the same network as the name server, the name server sorts the results so that the address closest to the client is at the top of the list for performance reasons. If the client is on a different network, the server cycles through the addresses in round-robin fashion. In one query, the first matching record is returned at the top of the list. In the second query, the second match is returned at the top of the list and so on. This gives the server the ability to essentially load-balance queries. For example, if you're hosting the same Web site on redundant servers, round-robin query results enable the DNS server to help balance the load across all of the servers.

CNAME stands for Canonical NAME. CNAME records map an alias name to a Fully Qualified Domain Name (FQDN). They are also called alias records. Host (A) records and CNAME records are usually applied in conjunction with one another. You might map a server's host name using an A record, then map (for example) www, FTP, and mail using CNAME records.

Mail Exchanger (MX) records are used to route e-mail. An MX record includes the FQDN of the mail server for the zone, along with a preference number from 0 through 65535. The preference number establishes priority for mail, and when there are multiple MX records with different preference numbers, the one with the lowest number is attempted first. Failing that, the sending server uses the record with the next highest number. If all MX records in the zone have the same preference number, the remote mail server decides which record to use to attempt mail delivery.

The Pointer (PTR) record is another common record type. PTR records perform the reverse of what host records do by mapping IP addresses to host names. PTR records enable reverse lookup. When you create or modify an A record, the Windows 2000 DNS service can automatically create or modify the associated PTR record for you.

Regardless of its type, each resource record has certain properties associated with it, and this information is stored along with the record in the zone file. Among these properties is a time-to-live (TTL) property that specifies the number of seconds the resolver should cache the record before it is considered stale and is discarded. When the specified TTL period is reached, the resolver discards the record and a subsequent attempt to resolve the name will pull it from the authoritative name server for the record rather than from the local cache.

The Internet is a dynamic place with hosts coming and going or changing their addresses frequently. The TTL enables records to be cached locally to improve response time and reduce the load on the network, since resolution doesn't go past the initially queried name server where the record is cached. When the record grows stale, the caching server (or resolver) throws it out, ensuring that the next query will pull an up-to-date version of the record.

Contact Us | Authors | Subject Index | RSS Feeds

Copyright ©2007