How DNS Works: A Primer

DNS has been in the news a great deal as of late. First, there was the controversy over the United States government essentially handing over control of the Internet's root domain naming system. Then DNS made headlines when cybercriminals performed three separate distributed denial of service (DDoS) attacks on a major DNS service provider by leveraging a botnet army of millions of compromised IoT devices. Yet with all the hoopla surrounding DNS, it surprises me how many IT pros don't fully understand DNS and how it actually works.

DNS stands for Domain Name System. Its purpose is to resolve and translate human-readable website names to IPv4 or IPv6 addresses. Technically speaking, it's not a necessary part of the networking processes. Rather, DNS simply makes it easier for human beings to know and remember what server they are trying to reach. For example, it's much easier to remember that if you want to perform an internet web search, you type in www.google.com as opposed to the IPv4 address of 216.58.217.4.

Most people in IT understand that DNS is used to translate domain names to IP addresses. Where things get sketchy is the actual operation of how DNS functions each time you use it. To illustrate how DNS works, let's pretend we're sitting at an internet-connected laptop with a web browser opened. We type www.networkcomputing.com into the search bar. Because this is a domain name as opposed to an IP address, our browser must find information on what IP address is associated with www.networkcomputing.com. Depending on several factors, this can be a single- or multi-step process.

The first place the browser checks is your web browser DNS cache. This cache is local to the browser application and the expiration timer for the cache is typically set low. For example, Firefox uses a 60-second cache timeout value. If the entry is not listed here, the browser then asks the local operating system DNS cache table. Like the web browser cache, operating systems maintain their own DNS table listing recently translated domain name to IP address lookups. That way, you're not wasting network resources continuously performing DNS lookups for commonly accessed domains. Typical OS DNS caching times, including modern Windows desktop operating systems, are usually set to 24 hours by default.

Let's assume in our example that we haven't visited www.networkcomputing.com for a few days. Therefore, our lookup in both our local application and OS DNS cache turn up no results. The next step is for the OS to query the DNS server that has either been statically assigned,  or provided through the DHCP process on the network interface currently in use. Within enterprise networks, this is typically an internally controlled server or set of servers. If you don’t maintain an internal recursive DNS servers, client devices may be pointed to a local DNS forwarder, a DNS service provider such as Cloudflare, Dyn or OpenDNS, or a public server like those operated by Google.

Now, if by chance, the recursive DNS server you reach out to doesn't have an entry for the domain name you're looking for, it can perform a DNS forward query to move up to yet another level in the DNS chain. In our example, if there is no match for www.networkcomputing.com in the recursive DNS server, the recursive server will first look to see if it knows of any servers in the networkcomputing.com domain. If not, it will then just look at .com.

As a last resort, it queries the Internet root servers. These servers control all the top-level domain (TLD) information for.com, .org and .us. The root server will then point the recursive server to the proper name server for the specific TLD, which in our example is .com. A trickle-down approach is then used to either find the domain-name-to-IP mapping, or give up at which time the recursive server would return a non-existent domain message back to the laptop that originated the query.

Knowing what DNS is and how it operates helps you understand you the ICANN controversy and how the recent rash of DDoS attacks on DNS servers crippled access to parts of the Internet where domain names are largely used. In last month's DDoS attack on Dyn, a botnet flooded it with millions of requests per second. These bogus requests bogged down the network and prevented real users from properly resolving their legitimate DNS requests.

DNS is a critical part of how we use IP networks today, and its management and security will continue to be hot topics of conversation.