Editor's note: In part one of a two-part series, Glen Kemp clarifies the function of the domain name system.
The domain name system (DNS) is a service fundamental to the Internet that is often taken for granted. This was brought home after a request to switch on a standard DNS system feature turned into an epic battle. I discovered that beyond the basic need to match host names to IP addresses, many administrators are fuzzy on the details of DNS. To that end, this guide is designed to "unfuzz" DNS for the enterprise administrator who has a new service to roll out, or just wants to learn more.
Explaining the name resolution process
When a client device connects to any Internet service, a DNS lookup is performed before anything else occurs. Some services, especially on internal networks, are hardcoded to use a specific IP address. While this approach is easy to get operational, services that use hard coding are less flexible; DNS provides a really useful layer of abstraction between applications and physical hosts. Network address translation and port address translation can be used to dig you out of this particular hole, but only by creating a larger one.
Internet hosts should be referenced by their fully qualified domain name (FQDN) -- the host name plus the associated domain name (for example, whatis.techtarget.com). A common host name for Web servers is www; we need the FQDN to tell us in which domain the server resides. When entering a URL, if a domain name is not included, the client will assume the target is on the local network, and that probably won't work.
Once users enter a remote URL, such as www.foo.com, into their browsers, several things happen. First, the cache of the DNS system resolver is checked. This is usually an operating system function, but some client applications (such as some mobile browsers) make their own arrangements. Next, the host file is checked. This simple text file is usually located in /etc and manually maps IP addresses to host names. If the client can't find a match in either the cache or host file, it will look elsewhere for an answer. To submit a query, the client must be configured with at least one DNS server. In corporate environments, this will be a local server. In mobile or home Internet scenarios, this service is usually provided by the ISP.
Starting from the end is the way to find the right address
Unlike IP addresses that get more specific from right to left, domain names get more specific from left to right. DNS has to work backwards from the top-level domain to the parent, and then to any child domains until it finds an IP address for the host.
If the DNS server doesn't find a cache hit, the request will be forwarded onto one of potentially many caching proxy servers. Ultimately, the request may end up at the global DNS root servers ("."), which in turn, point to the top-level domain servers (TLDs). The TLDs control the major domains, such as .com, .org and .uk. In turn, these then point to the child domains, in our case, foo.com.
The diagram below shows the query's path from client to the address via the root servers and top-level and parent domains.
You need to be concerned only with the responses received from the configured DNS servers; these are the only ones with which the client has any relationship. Because there are many public servers, it's easy to rule out server-side issues by just selecting another.
Eventually (i.e., usually under a second), the client will get one of several responses from its DNS server. If that response includes an IP address, the client will then open a TCP socket to that destination. It's seldom that simple, however. In a world of content delivery networks and affiliate websites, it's rare that a single URL results in a single IP address response. In the next part of this series, I'll explore the responses a seemingly simple DNS request can elicit.