DNS is responsible for mapping host names to IP addresses and vice versa. It is the service that allows you to connect to Novell’s Web server by entering www.novell.com, instead of having to remember the system’s IP address. All IP routing is done with addresses, not names. While IP systems do not use names when transferring information, names are easier for people to remember; DNS was developed to make reaching remote systems that much easier. DNS allows a person to enter an easy-to-remember name while allowing the computer to translate this into the address information it needs to route the requested data.
DNS follows a hierarchical, distributed structure. No single DNS server is responsible for keeping track of every host name on the Internet. Each system is responsible for only a portion of the framework.
Figure 3.18 shows an example of how DNS is structured. Visually it resembles a number of trees strapped to a pole and hanging upside down. The pole is not meant to represent the backbone of the Internet; it simply indicates that there is DNS connectivity between the different domains. The systems located just below the pole are referred to as the root name servers. Each root name server is responsible for one or more top-level domains. Examples of top-level domains are the .com, .edu, .org, .mil, or .gov found at the end of a domain name. Every domain that ends in .com is said to be part of the same top-level domain.
Figure 3.18: A visual representation of the hierarchical structure of DNS
The root name servers are responsible for keeping track of the DNS servers for each subdomain within a top-level domain. They do not know about individual systems within each subdomain, only the DNS servers that are responsible for them. Each subdomain DNS server is responsible for tracking the IP addresses for all the hosts within its domain.
Let’s walk through an example to see how it works. Let’s say you’re part of the foobar.com domain. You are running a Web browser and have entered the following URL:
http://www.sun.com
Your system will first check its DNS cache (if it has one) to see if it knows the IP address for www.sun.com. If it does not, it forms a DNS query (a DNS query is simply a request for IP information) and asks one of the DNS servers within the foobar.com domain for the address. Let’s assume the system it queries is ns.foobar.com. If ns.foobar.com does not have this information cached, it also forms a DNS query and forwards the request to the root name server responsible for the top-level domain .com, because this is where the Sun domain is located. The root name server will consult its tables and form a reply similar to this: “I do not know the IP address for www.sun.com. I do, however, know that ns.sun.com is responsible for all the hosts within the sun.com domain. Its IP address is 10.5.5.1. Please forward your query to that system." This reply is then sent to ns.foobar.com.
Ns.foobar.com now knows that if it needs to find a system with the sun.com domain, it needs to ask ns.sun.com. Ns.foobar.com caches this name server information and forwards the request to ns.sun.com.
Ns.sun.com will in turn consult its tables and look up the IP address for www.sun.com. Ns.sun.com will then forward the IP address to ns.foobar.com. Ns.foobar.com will then cache this address and forward the answer to your system. Your system can now use this IP address information to reach the remote Web server.
If you think that there is a whole lot of querying going on, then you have a good understanding of the process. The additional traffic is highly preferable, however, to the amount of overhead that would be required to allow a single
As you may have noticed, DNS makes effective use of caching information during queries. This helps to reduce traffic when looking up popular sites. For example, if someone else within foobar.com now attempted to reach www.sun.com, the IP address for this system has been cached by ns.foobar.com. It can now answer this query directly.
The amount of time that ns.foobar.com remembers this information is determined by the time to live (TTL) set for this address. The TTL is set by the administrator responsible for managing the remote name server (in this case ns.sun.com). If www.sun.com is a stable system, this value may be set at a high value, such as 30 days. If it is expected that the IP address for www.sun.com is likely to change frequently, the TTL may be set to a lower value, such as a few hours.
Caveats about the TTL Settings
Let’s look at an example to see why it is important to properly manage your TTL settings. Let’s say the mail relay for foobar.com is run from the system mail.foobar.com. Let’s also assume that a high TTL value of 30 days has been set in order to reduce the number of DNS queries entering the network from the Internet. Finally, let’s assume that your network has changed ISPs and you have been assigned a new set of IP numbers to use when communicating with the Internet.
The network is readdressed, and the changeover takes place. Immediately users begin to receive phone calls from people saying that mail sent to their address is being returned with a delivery failure notice. The failure is intermittent—some mail gets through, while other messages fail.
What went wrong? Since the TTL value has been set for 30 days, remote DNS servers will remember the old IP address until the TTL expires. If someone sent mail to the foobar.com domain the day before the changeover, it may be 30 days before their DNS server creates another query and realizes that the IP address has changed! Unfortunately, the domains most likely affected by this change are the ones you exchange mail with the most. There are two ways to resolve this failure:
1. Ignore it and hide under your desk. Once the TTL expires, mail delivery will return to normal.
2. Contact the DNS administrator for each domain you exchange mail with and ask them to reset their DNS cache. This will force the remote system to look up the address the next time a mail message must be sent. This option is not only
embarrassing—it may be impossible when dealing with large domains such as AOL or CompuServe.
Avoiding this type of failure takes some fundamental planning. Simply turn down the TTL value to an extremely short period of time (like one hour) at least 30 days prior to the changeover. This forces remote systems to cache the information for only a brief amount of time. Once the changeover is complete, the TTL can be adjusted back up to 30 days to help reduce traffic. Thirty days is a good TTL value for systems that are not expected to change their host name or address.
Note DNS uses TCP and UDP transp orts when comm unicati ng. Both use a destina tion port of 53.