What is a DNS server? It resolves DNS queries

The answer to “What is a DNS server?” is that it responds to and resolves DNS queries from devices.

DNS servers are critical to network operations. Without DNS servers, devices like computers or smartphones would not be able to communicate across a network or access the internet.

The Domain Name System (DNS) is a hierarchical naming system that facilitates communication across devices on a network. More specifically, it translates human-readable domain names (like bluecatnetworks.com) to computer-friendly Internet Protocol (IP) addresses (like 104.239.197.100 in IPv4).

DNS allows us to connect to websites without having to memorize a string of IP address numbers. With DNS, all we need to know when we open web browsers are websites’ names. Devices like your smartphone request information from DNS servers to locate the IP address for the domain name of a website.

In this glossary entry, we’ll touch on the basics of what a DNS server is. Then, we’ll unpack the eight steps that a DNS server typically undertakes to complete a DNS query. Finally, we’ll explore what it means when your DNS server is not responding.

What is a DNS server?

The DNS namespace is the entirety of the internet’s registered domain names. It is organized hierarchically in a tree-like structure. The root domain sits at the top of the tree, with top-level domains (TLDs) below. (A TLD is the last part of a domain, such as .com or .org.). Second-level domains—like “example” in example.com—follow next.

A DNS server (also called a nameserver) stores DNS records and/or communicates with other servers. When a query is sent by a client device, resolvers and nameservers step in. They ensure that the query gets a response from the relevant record.

You direct your computer or smartphone, also called a client device, to visit a website. To do so, your device sends out a DNS query or request. A stub resolver is the part of a client device that facilitates these requests.

There are two types of DNS servers that then step in. These are recursive resolvers (or recursive DNS servers) and authoritative nameservers (also called authoritative DNS servers).

The latter includes root servers as well as TLD servers. Typically, these work together with authoritative nameservers in a lookup chain to deliver an IP address to a client device.

Notably, DNS servers can exist in many forms. They can be a physical server box or a virtual server. They can even be implemented as a server-less function in AWS (called Route 53) or a container on Kubernetes.

Queries to DNS servers happen all the time

DNS queries, also known as DNS lookups, are happening all the time.

Some of them take place within your network—internal DNS queries never make it to the public internet. DNS servers that are part of on-premises local area networks (LANs) are essential for network operations. Without them, users—and their devices—on the network would not be able to connect to local servers and printers. In enterprise settings, there is usually a dedicated internal DNS server that resolves internal DNS queries inside your network.

On the other hand, for external websites, queries are sent outside of your network and rely on external servers for resolution.

Furthermore, in today’s hybrid cloud enterprise environments, DNS servers play a crucial role. Once upon a time, all you needed to use Microsoft Word was a computer and the installed software. Now, enterprise users mostly utilize software-as-a-service applications (such as Office 365). And many enterprise applications now reside in an infrastructure-as-a-service cloud rather than on a data center server.

For any of those set-ups, DNS servers must point users to their application destination.

Eight steps for a DNS server to complete a lookup

Many scenarios require a lookup. Here are eight basic steps for a very common one using a web browser:

1. A user types example.com into a web browser, such as Google Chrome. After that, the client device asks for IP address information and tries to find the answer locally on the device. If it can’t, the next step is a…
2. Recursive resolver. This is a type of DNS server between a client and authoritative name servers. Your enterprise IT department usually provides one or more recursive resolvers. At home, your internet service provider (ISP) probably provides some. However, some may opt to use public DNS servers instead (there is a list of DNS servers available for the public). After receiving a query, a recursive resolver will, most of the time, respond to it with cached information. But if it cannot find the answer, it will send a request on to a…
3. Root nameserver. This is the first step in translating domain names to IP addresses. Its main job is to point to other more specific server locations. It responds to the resolver with the name of a TLD nameserver, which stores the information for its domains.
4. The recursive resolver sends a request to the TLD nameserver.
5. The TLD nameserver responds with the names and possible IP addresses of the requested domain’s authoritative nameservers.
6. The recursive resolver sends a request to the authoritative nameserver at the end of the lookup chain. The authoritative nameserver holds and is the final arbiter of DNS records (officially called resource records). As the last stop in the process, this server can return the record needed by the web browser.
7. The authoritative nameserver returns the requested data to the recursive resolver.
8. The recursive resolver responds to the web browser with the requested data and the user gets their answer.

DNS caching

DNS record information will often be cached locally inside a client device or somewhere in the DNS server hierarchy. Certainly, DNS caching results in more efficient query resolution.

In practice, it’s relatively rare to have an empty cache. Effective caching will often allow for bypassing steps. But the cache cannot initially populate without querying all of the key players in the server hierarchy as outlined above.

As mentioned above in step 2, a recursive resolver can respond with cached information, circumventing further steps and delivering the record. Furthermore, steps 3 through 5 as outlined above assume that nothing is cached in the nameservers. But with caching, steps 3 to 5 would look more like this:

If the recursive resolver in step 2 can’t find the answer, it will send its request on to…

3. The best nameserver it knows from its cache. This might be a root nameserver (at the top of the internet’s namespace tree), which every recursive resolver must know about.
4. The queried nameserver returns the best answer it knows. This is often a referral to another set of authoritative nameservers, which know about data lower down on the namespace tree.
5. The recursive resolver will repeat steps 3 and 4, working its way down the namespace tree and caching everything it learns.

Then it proceeds with step 6 as outlined above and sends a request to the authoritative nameserver.

Time to live (TTL)

Furthermore, most stub resolvers are also designed to cache records for a while, known as the time to live (TTL). Once the TTL expires, the next time the client needs to know that address, it starts again at step 2 above. Querying its configured recursive nameserver(s) then begins again. Many factors can affect what administrators set TTL at in their DNS server infrastructure.

Recursive nameservers should respect TTLs. However, it’s often more expedient to continue to serve stale data that can’t be looked up again for a time. This increases the resilience of DNS lookups in the face of temporary network failures.

Two types of DNS queries

It’s also important to note that there are generally two types of DNS queries:

Recursive query: The local DNS resolver must provide a complete answer when it responds to the client device. The resolver first looks in its local cache. If it can’t find any answer there, it will look to other DNS servers in the infrastructure. It will try the request until it gets a complete response to return to the client.

Non-recursive (or iterative) query: DNS servers do not always provide complete answers to client devices. If they don’t have one, the answer they return refers clients to other DNS servers that might have it. The process for the client repeats (iterates) until it finds a server that has the answer.

Iterative queries are often faster than recursive queries. The queried server doesn’t need to ask any other servers to build the response.

Certainly, queries don’t always resolve successfully. If they don’t, DNS response codes can provide clues as to what the problem may be.

What if my DNS server is not responding?

Usually, you get a “DNS server not responding” error for one of two reasons. It could be that the DNS of the domain you want to reach is unavailable. Or your web browser can’t establish a connection to the internet.

Servers themselves can sometimes be to blame for this error message. The culprit might be a power outage, hardware failure, or a distributed denial-of-service (DDoS) attack. (Remember the massive 2016 DDoS attack against DNS provider Dyn?)

User error is often to blame

However, it’s also not uncommon for the problem to be on the user end. It could be a problem with your network connection, misconfigured settings, or even an outdated web browser.

Users can usually fix the problem with simple steps. These might include troubleshooting network settings, switching to a different device or browser, or restarting your router. Further efforts might involve disabling connections, changing DNS servers, or flushing your DNS cache.

Common prevention measures: High availability, anycast, and automation

To avoid errors due to hardware failures, most DNS server infrastructure today is built with redundancy in mind. (Redundancy is sometimes called high availability.) Most ISPs have backup recursive resolvers, and there are usually multiple instances of root and TLD nameservers. Websites typically have backup authoritative nameservers as well.

Furthermore, to ensure uptime, DNS servers usually employ anycast routing. Anycast allows for multiple servers on the network to use the same IP address. This means that any number of DNS servers can respond to queries from anywhere around the world.

Typically, to reduce latency, the geographically closest server to a client provides responses. But if that one goes down, other servers that remain active and accessible can provide it instead.

Automation can also reduce the risk of human error as well as increase efficiency.

DNS automation tools can allow IT staff and end-users to stand up or decommission new servers and services themselves. DNS records can be automatically created or updated in seconds.

BlueCat can help enterprises make their networks more automated and resilient. Bringing the core services of DNS, DHCP, and IP address management together into a BlueCat platform solution can transform network management.