In the early ARPANET years, all these machine names and addresses were kept in one master hosts file (/etc/hosts) at Stanford University. Every time a new machine or group of machines was added to the network, updates had to be sent out to all the other universities and military installations attached to the network. As you can imagine, this grew to quite a task! Think of all the potential problems with records synchronization and IP/name conflicts, not to mention the single-point-of-failure issue.
In 1984 RFC 1034 was released. This document described a new way in which machine namespace could be delegated, decentralized, and configured. The DNS utilizes a client/server configuration that allows any user to get to any Fully Qualified Domain Name, or FQDN, in a short amount of time. DNS brought almost total reliability and nearly infinite scalability to the growing Internet.
DNS is divided into three parts: the namespace, the resolver, and the servers. To continue with the phonebook analogy, the namespace is the section of the phonebook that contains phone listings. The resolver is the program that asks for DNS information and, by extension, the user looking up the address. Finally, DNS servers are machines all over the Internet and provide DNS information: in this example, multiple copies of the phonebook. These three components create a functionally delegated system that resolves names to addresses and vice versa.
How does DNS work? It's easiest to imagine if you think of the Internet as a top-down tree (Figure 12-1). At the very top, there are 13 root name servers that are spread across the planet. All these name servers do is point requests to the next layer of machines, the Top-Level Domain Servers. Each of these servers then provides data to another level of servers, and so on. Much like your hard drive filesystem, domain namespace is small at the top level and increasingly complex the deeper you delve.
The 13 root name servers at the top of the tree diagram are named A. ROOT-SERVERS.NET. through M. ROOT-SERVERS. NET. Notice the trailing dot in the machine names? This is critical for DNS service, as the terminating dot gives the DNS name an absolute reference point, much like a file on your hard drive is described by its full path name including drive and filename designation. Without the top level / how would you know where the file was located? Similarly, if a domain name does not have a terminating dot, your computer can't tell whether www.yahoo.com is really www.yahoo.com.nike.coin or some other nested address. You might be able to figure it out, but your machine can't.
Between the 13 root name servers and the top-level domain (TLD) servers, you'll find name servers at the Registrar level. These registrar name servers control a set of TLD name servers. When you buy a domain name from a registrar, you must supply the IP addresses of two name servers managed by you or by your Internet provider. In doing so, control of your domain name is delegated, or handed down, from the registrar to your provider. When a search is clone on your domain name, the last name server IP given is the one you or your provider controls.
Once the registrar delegates control to the name servers you provided, these become the authoritative name servers for your domain. Any client or user that does a DNS search on your domain name will now ultimately come to your name server to resolve fully qualified domain names in your namespace and match them to the actual IP addresses of your hosts. This is why it is critical to keep your primary and secondary DNS server listings up to date with the registrar who handles all your domain names. If the server information is incorrect, authority for the domain name has been delegated to the wrong machine.
Every domain on the Internet relies on at least two name servers: a primary server and a secondary server (from the client perspective). These registrar designations usually refer ultimately to what are called master and slave DNS servers. As its name implies, the master server is the main name server for that domain. It holds the master copy of the domain files describing each domain for which it is authoritative. It's the master name server's job to store the latest copy of the zone files-files that contain all the pointers that connect machine names and aliases to IP addresses within your domain.
The slave server contains copies of the master zone files, which it downloads from the master server on a regular basis. These downloads are called zone transfers. You might also see tertiary, or third-level, name servers, though they are the exception rather than the rule.
Note |
If you want to learn more about the functions of master and slave DNS servers, consult www.tldp.org/HOW TO/DNS-HOWTO-5.html#ss5.6. |
While many web administrators set up master and slave DNS services on a single machine, this is rarely a good idea. If DNS service goes down on that machine or is blocked for some reason, then nobody outside the local network can see your name server. Thus, nobody can see the domains over which that server has authority. It's best to set up your slave DNS server on another network, or even with another provider altogether (unless your provider can offer you a multinetwork, multidata center DNS hosting solution).
Tip |
Some hosting or network providers will split DNS hosting with you, running either master or slave DNS service on their system and letting you run the other component on your local server. This might save you from having to buy a second machine just to host half your DNS service. |
DNS caching is the function that makes the modern Internet usable. DNS caching is nothing more than a local machine holding onto the DNS information from external zones for a given amount of time. If it were not for DNS caching, most Internet traffic would be nothing but DNS queries for domain names and IP addresses.
Your local ISP, along with other ISPs and networks, usually provide some level of DNS caching to their internal network users.
The amount of time for which information is cached (aka the TTL or Time to Live value) is determined by the master zone file of a given domain, and set by the domain owner or DNS administrator. The TTL can be as short as a second or a few minutes, to 24 hours, to a week or more. Twenty-four hours is a typical setting. Caching name servers all around the world should honor these TTL values and treat cached information as "official" for that defined period before requesting the domain information from the authoritative server again.
For example, assume that you are the first person from your ISP to type www.example.com into your browser. Your browser contacts your ISP's DNS server to find the IP information for www.example.com. In turn, your ISP goes on your behalf to the root domain name server, then to the TLD and registrar servers, and finally to the authoritative name server for the requested domain with a request for the IP address associated with www.example.com. Once this chain of requests is complete, the IP information remains cached at your ISP's DNS server for the period of time defined in www.example.com's master zone file's TTL setting.
Note |
When a DNS server need only consult its cache to find the requested IP information rather than pass the request to remote name servers, the query is called a recursive query. If you ask a DNS server to map a fully qualified domain name to an IP address but the server does not already have the information in its cache, it will go and get the information rather than simply saying "I don't know." Most DNS servers that do recursive queries also provide DNS caching, to lessen the load of individual requests. |