Understanding what is DNS

DNS resembles a global telephone directory, except that rather than look up the phone number and dial it as you do with your "landline" phone or cell phone, you simply type into your "phone" (your Web browser) the name of the party you're trying to contact, and the party is contacted automatically. DNS is useful because it's much easier to remember a name like www.davidthegeek.blogspot.com than an address like 192.168.100.5.

Although DNS seems like a big phone book full of names and IP addresses, it's much more complex than that. It's laid out in a hierarchical manner, for two reasons: It removes the requirement to have either one large directory that everyone uses or to have every directory contain every DNS name and IP address in existence. Instead, a large number of DNS servers exist; they're distributed and then queried only for the addresses they contain. If a DNS server houses the zone for a certain domain, it's known as authoritative for that domain.

The best way to understand how a DNS request is processed is to follow along step-by-step. In this example, assume that the DNS name is www.microsoft.com and that the recursive DNS server's cache is empty:

1. You type a DNS name, such as www.microsoft.com, in your Web browser or any other DNS–enabled software.

2. The DNS client, which is usually part of the operating system, is called. The DNS client is contained in a dynamic loaded library (DLL) in Windows. In Unix, however, the process works a little differently: The application passes the DNS name to the DNS client and waits for a response, including the corresponding IP address or an error.

3. The DNS client then takes over. It makes the DNS request to the DNS server that's configured in your network settings. The DNS servers are set in the network properties in Windows or in the resolv.conf file in Unix. The DNS client doesn't do any resolution itself; it only passes the request from the application to the DNS server. The DNS client's job is to accept the request from the application in a format the application understands, convert the request to a proper DNS request that the server understands, and then convert the response again and return it to the application.

4. The DNS server configured in the client's network settings receives the request. This DNS server must be a recursive DNS server, which means that it can process requests for domains for which it isn't authoritative. Some DNS servers have recursion disabled and cannot process requests unless they're for the requested domain.

5. The recursive DNS server begins the resolution process. It first looks at the DNS name in the request in reverse order. In this case, the DNS name is www.microsoft.com. — with the trailing period. The first thing the DNS server notices is the trailing period, indicating the root of the DNS namespace. Because the recursive DNS server already has addresses for the root DNS servers in a root hints file, it doesn't need to look up that address (it can't because no DNS server is above the root in the hierarchy).

6. The recursive DNS server picks a root server from its root hints file and requests the address for the server hosting the next component of the DNS name — in this case, .com. The root server returns a list of name servers that are authoritative for .com, and the recursive DNS server caches those servers as authoritative for .com so that it doesn't need to make the request again until the TTL expires.

7. The recursive server then chooses an authoritative server for .com from the list returned by the root server and sends a request for the name server authoritative for the .microsoft.com domain.

8. The .com authoritative server returns a list of authoritative servers, and the recursive DNS server caches that list in association with .microsoft.com.

9. Now that the recursive server has resolved the entire domain name, all that's left is to resolve the IP address of the host. It chooses an authoritative server from the list for .microsoft.com and sends a request for the host (A) record associated with www.microsoft.com. The authoritative server for .microsoft.com returns all the A records for www (if there's more than one) to the recursive DNS server. Round robin DNS then occurs. The authoritative server returns the A records in order of the lowest metric first, or, if the metrics are equal, it rotates the order in which it returns the records with each request. The recursive server caches the list of A records associated with www.microsoft.com.

10. The recursive DNS server returns the list of A records to the DNS client. The client decides which IP address to use. According to the DNS standards, the client is supposed to use the first address in the list (if there's more than one). By default, however, Windows 2000 and newer DNS clients place priority on IP addresses on the local subnet, although this behavior can be disabled.

11. When the DNS client has decided which address to return to the application, it formats the IP address data in the correct format and returns it to the application through the appropriate communication channel.

12. The application can now use the IP address to open a socket to the remote host and begin the network communication.

Although this process seems arduous, it's fast (relative to a human timeframe — in computer time, it's slow). A huge advantage also exists in this massively distributed architecture: Although the root servers must be incredibly powerful and the servers that are authoritative for the top-level domains must be fairly powerful — especially for the busier TLDs, such as .com — the lower-level name servers don't need to be powerful. At a company doing Web hosting, for example, the root servers may be authoritative for 1,000 domains, but they can have one moderately powered system hosting all 1,000 domains or 10 slow machines hosting 100 domains each, and it makes no difference to users or any other DNS server.