DNS and Protocol Part II

DNS is a client/server service; however, it differs from the other client/server services that we are examining. While other services use a client that is an application (such as web browser, e-mail client), the DNS client runs as a service itself. The DNS client, sometimes called the DNS resolver, supports name resolution for our other network applications and other services that need it.

When configuring a network device, we generally provide one or more DNS Server addresses that the DNS client can use for name resolution. Usually the Internet service provider provides the addresses to use for the DNS servers. When a user's application requests to connect to a remote device by name, the requesting DNS client queries one of these name servers to resolve the name to a numeric address.

Computer operating systems also have a utility called nslookup that allows the user to manually query the name servers to resolve a given host name. This utility can also be used to troubleshoot name resolution issues and to verify the current status of the name servers.

In the figure, when the nslookup is issued, the default DNS server configured for your host is displayed. In this example, the DNS server is dns-sjk.cisco.com which has an address of 171.68.226.120.

We then can type the name of a host or domain for which we wish to get the address. In the first query in the figure, a query is made for www.cisco.com. The responding name server provides the address of 198.133.219.25.
The queries shown in the figure are only simple tests. The nslookup has many options available for extensive testing and verification of the DNS process.

A DNS server provides the name resolution using the name daemon, which is often called named, (pronounced name-dee).

The DNS server stores different types of resource records used to resolve names. These records contain the name, address, and type of record.

Some of these record types are:
A - an end device address
NS - an authoritative name server
CNAME - the canonical name (or Fully Qualified Domain Name) for an alias; used when multiple services have the single network address but each service has its own entry in DNS
MX - mail exchange record; maps a domain name to a list of mail exchange servers for that domain

When a client makes a query, the server's "named" process first looks at its own records to see if it can resolve the name. If it is unable to resolve the name using its stored records, it contacts other servers in order to resolve the name.

The request may be passed along to a number of servers, which can take extra time and consume bandwidth. Once a match is found and returned to the original requesting server, the server temporarily stores the numbered address that matches the name in cache.

If that same name is requested again, the first server can return the address by using the value stored in its name cache. Caching reduces both the DNS query data network traffic and the workloads of servers higher up the hierarchy. The DNS Client service on Windows PCs optimizes the performance of DNS name resolution by storing previously resolved names in memory, as well. The ipconfig /displaydns command displays all of the cached DNS entries on a Windows XP or 2000 computer system.

The Domain Name System uses a hierarchical system to create a name database to provide name resolution. The hierarchy looks like an inverted tree with the root at the top and branches below.

At the top of the hierarchy, the root servers maintain records about how to reach the top-level domain servers, which in turn have records that point to the secondary level domain servers and so on.

The different top-level domains represent the either the type of organization or the country or origin. Examples of top-level domains are:
.au - Australia
.co - Colombia
.com - a business or industry
.jp - Japan
.org - a non-profit organization

After top-level domains are second-level domain names, and below them are other lower level domains.

Each domain name is a path down this inverted tree starting from the root.

For example, as shown in the figure, the root DNS server may not know exactly where the e-mail server mail.cisco.com is located, but it maintains a record for the "com" domain within the top-level domain. Likewise, the servers within the "com" domain may not have a record for mail.cisco.com, but they do have a record for the "cisco.com" domain. The servers within the cisco.com domain have a record (a MX record to be precise) for mail.cisco.com.

The Domain Name System relies on this hierarchy of decentralized servers to store and maintain these resource records. The resource records list domain names that the server can resolve and alternative servers that can also process requests. If a given server has resource records that correspond to its level in the domain hierarchy, it is said to be authoritative for those records.

For example, a name server in the cisco.netacad.net domain would not be authoritative for the mail.cisco.com record because that record is held at a higher domain level server, specifically the name server in the cisco.com domain.

Links

http://www.ietf.org//rfc/rfc1034.txt

http://www.ietf.org/rfc/rfc1035.txt