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? In this Daily Drill Down, I’ll take a brief look at DNS and show you some of its ins and outs.
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 that 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 www.newsmax.com instead of 64.29.200.227. 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.
About those 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 techrepublic.com. So, your computer’s Fully Qualified Domain Name (FQDN) is rainbow.techrepublic.com. The FQDN identifies the host uniquely within the DNS name space.
Domains aren’t limited to a single level. Assume techrepublic.com has two different divisions, one on the east coast and one on the west coast. The east coast domain is east.techrepublic.com and the other is west.techrepublic.com. Sales is located on the west coast, so its domain is sales.west.techrepublic.com. Joe Blow, who works in the sales department, has a computer named jblow. Its FQDN is jblow.sales.west.techrepublic.com. Traffic reaches his computer through something called delegation, which I’ll cover a little later.
The DNS name space contains seven common domain suffixes, which are listed in Table A.
There are other domain suffixes as well, including national domains such as the us domain, which is used for governmental, regional, and educational entities in the United States. Other countries have their own domains, such as jp for Japan, uk for the United Kingdom, and so forth.
Until recently, an organization known as InterNIC was 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 techrepublic.com, for example, and within those name servers the west.techrepublic.com domain is delegated to another set of name servers that manage that portion of the overall techrepublic.com 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 www.techrepublic.com. 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 techrepublic.com. 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 techrepublic.com domain. Your ISP’s name server then builds another request for www.techrepublic.com and submits it to techrepublic.com’s name server, which responds with the IP address of www.techrepublic.com. That information is passed back to your resolver, which passes it to your application. Suddenly, techrepublic.com’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.
How about those 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. Table B lists resource record types supported by the Windows 2000 DNS service.
As you can see in Table B, 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.
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 that 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 www.newsmax.com instead of 64.29.200.227. 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.
About those 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 techrepublic.com. So, your computer’s Fully Qualified Domain Name (FQDN) is rainbow.techrepublic.com. The FQDN identifies the host uniquely within the DNS name space.
Domains aren’t limited to a single level. Assume techrepublic.com has two different divisions, one on the east coast and one on the west coast. The east coast domain is east.techrepublic.com and the other is west.techrepublic.com. Sales is located on the west coast, so its domain is sales.west.techrepublic.com. Joe Blow, who works in the sales department, has a computer named jblow. Its FQDN is jblow.sales.west.techrepublic.com. Traffic reaches his computer through something called delegation, which I’ll cover a little later.
The DNS name space contains seven common domain suffixes, which are listed in Table A.
| Suffix | Purpose | Example |
| .com | Commercial organizations (businesses) | microsoft.com |
| .edu | Educational organizations such as colleges and universities | berkeley.edu |
| .gov | Governmental organizations | nasa.gov |
| .mil | Military organizations | army.mil |
| .net | Networking organizations such as ISPs | mci.net |
| .org | Noncommercial organizations such as the IEEE standards body | ieee.org |
| .int | International organizations such as NATO | nato.int |
There are other domain suffixes as well, including national domains such as the us domain, which is used for governmental, regional, and educational entities in the United States. Other countries have their own domains, such as jp for Japan, uk for the United Kingdom, and so forth.
Until recently, an organization known as InterNIC was 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 techrepublic.com, for example, and within those name servers the west.techrepublic.com domain is delegated to another set of name servers that manage that portion of the overall techrepublic.com 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 www.techrepublic.com. 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 techrepublic.com. 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 techrepublic.com domain. Your ISP’s name server then builds another request for www.techrepublic.com and submits it to techrepublic.com’s name server, which responds with the IP address of www.techrepublic.com. That information is passed back to your resolver, which passes it to your application. Suddenly, techrepublic.com’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.
How about those 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. Table B lists resource record types supported by the Windows 2000 DNS service.
| Record | Purpose |
| SOA | Specifies authoritative server for the zone |
| NS | Specifies address of domain’s name server(s) |
| A | Maps host name to an address |
| PTR | Maps address to a host name for reverse lookup |
| CNAME | Creates alias (synonymous) name for specified host |
| MX | Mail exchange server for domain |
| SRV | Defines servers for specific purpose such as HTTP, FTP, and so on |
| AAAA | Maps host name to Ipv6 address |
| AFSDB | Location of AFS cell database server or DCE cell’s authenticated server |
| HINFO | Identifies host’s hardware and OS type |
| ISDN | Maps host name to ISDN address (phone number) |
| MB | Associates host with specified mailbox; experimental |
| MG | Associates host name with mail group; experimental |
| MINFO | Specifies mailbox name responsible for mail group; experimental |
| MR | Specifies mailbox name that is proper rename of other mailbox; experimental |
| RP | Identifies responsible person for domain or host |
| RT | Specifies intermediate host that routes packets to destination host |
| TXT | Associates textual information with item in the zone |
| WKS | Describes services provided by specific protocol on specific port |
| X.25 | Maps host name to X.121 address (X.25 networks); used in conjunction with RT records |
| WINS | Allows lookup of host portion of domain name through WINS server |
| WINS-R | Reverses lookup through WINS server |
| ATMA | Maps domain name to ATM address |
As you can see in Table B, 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.
No comments:
Post a Comment