How does a DNS query work?

When you open your browser and type in “www.example.com”, or a DNS client needs to look up a name used in a program, it queries DNS servers to resolve the name. Each query message the client sends contains three pieces of information, specifying a question for the DNS server to answer:

• A specified DNS domain name, stated as a fully qualified domain name (FQDN) such as “www.example.com”
• A specified query type, which can either specify a resource record by type or a specialized type of query operation such as A, CNAME, NS etc.
• A specified class for the DNS domain name such as IN (Internet)

Say what?

Yep, all of that is fairly technical mumbo jumbo about the actual content of a DNS request, and it is behind the scenes. Let’s simplify it by demonstrating how it works with something you do every day. Here is how it works visually if you were to open your browser and attempt to go to a website.

A DNS query example

I this example, the destination URL (name) specified could be the FQDN for a website, such as “example.com.”, and the query type specified to look for an address (A) resource record by that name (it’s an ‘A’ record query because we want the IP address).

Think of a DNS query as a client asking a server a two-part question, such as “Do you have any ‘A’ resource records for a website named ‘example.com.’?” When the client receives an answer from the DNS server, it reads and interprets the answered ‘A’ resource record, learning the IP address for the computer it asked for by name.

DNS Cache

DNS queries resolve in a number of different ways. A client can sometimes answer a query locally using cached (stored) information obtained from a previous query. The DNS server can use its own cache of resource record information to answer a query.

A DNS server can also query or contact other DNS servers on behalf of the requesting client to fully resolve the name, then send an answer back to the client. This process is known as recursion. It is depicted in the image above where the DNS Resolver does not have the answer, so it has to go to the root server. The root server directs to the correct TLD server for the actual answer which is then forwarded back to the user.

The length of time the answer stays in the cache is determined by the TTL (time-to-live) set by the owner of the domain who created the record in the first place. Properly built recursive DNS servers will obey this and discard the cache after the TTL expires, but there are still ISPs that improperly ignore this critical information for a variety of reasons.

In addition, the client itself can attempt to contact additional DNS servers to resolve a name. When a client does so, it uses separate and additional queries based on referral answers from servers. This process is known as iteration. For example, if I ask for ‘www.example.com’, an ‘A’ record might not exist. It might actually return a CNAME telling me that I should make another request to find out what the IP address is.

In general, the DNS query process occurs in two parts:

• A name query begins at a client computer and is passed to a resolver, the DNS Client service, for resolution.
• When the query cannot be resolved locally, DNS servers can be queried as needed to resolve the name.

When it doesn’t work…

As you can see, there is more than meets the eye when it comes to DNS query resolution. If a DNS server does not provide an answer in a timely fashion, it can slow everything down. Until your browser knows the IP address for the URL you entered, it can’t do anything but wait. That’s why it’s important for authoritative DNS servers to be fast. Furthermore, if an authoritative DNS server goes down, then the query will eventually time-out and no answer will be provided. You’ve probably seen that from time-to-time as you perused the Internet clicking on a link for a site that never arrives.