Every time we open a website, we usually type a domain name into our browser rather than an IP address. For example, we type yahoo.com instead of remembering a numerical address such as 203.0.113.10.
Computers communicate over networks using IP addresses, so how does a browser know which IP address belongs to a domain name?
The answer is DNS (Domain Name System).
DNS is a distributed, hierarchical naming system that translates domain names into information computers can use to locate services on a network.
Think of DNS as the internet's phone-book, but it is more accurate to think of it as a distributed directory.
To understand how this works, let's follow what happens when someone enters yahoo.com into a browser.
1. The DNS resolution process
DNS resolution involves several components working together:
- DNS resolver: Receives the lookup request and finds the answer on behalf of the client.
- Root name servers: Direct the resolver toward the correct top-level domain servers.
-
TLD name servers: Handle a particular top-level domain, such as
.com. -
Authoritative name servers: Provide the DNS records for a domain, such as
yahoo.com. - DNS cache: Stores previously obtained DNS information so it can be reused while valid.
Here is the simplified lookup process:
- You enter
yahoo.comin your browser. - Your device checks if its available DNS caches.
- If no usable answer is found, it sends a query to a recursive DNS resolver.
- The resolver queries a root name server.
- The root server directs it to the
.comTLD name servers. - The TLD server directs it to the authoritative name servers for
yahoo.com. - The authoritative server returns the requested DNS record, such as an IP address or a CNAME record.
- The resolver caches the response when appropriate and returns the answer to your device.
- Your browser can then connect to the destination using the resolved address.
This is a simplified example. In practice, some steps may be skipped because of caching, and the actual DNS records returned can vary.
2. Understanding the DNS components
A. DNS resolver - the coordinator
The resolver is the component responsible for finding the answer to a DNS query.
Your device commonly sends its request to a recursive resolver, which may be operated by your internet service provider, an organization, or a public DNS provider.
For example, when you request yahoo.com, the resolver tries to obtain the appropriate DNS record on your behalf.
It may already have the answer in its cache. If it does, it can return the answer immediately without contacting other DNS servers.
If the answer is not cached, the resolver performs the necessary queries to locate it.
Think of the resolver as someone looking up a person's contact details. Instead of asking you to contact several directories yourself, the resolver does the searching and returns the result.
B. Root name servers - finding the right direction
If the resolver does not already have a usable answer, it can begin by querying a DNS root server.
Root name servers sit at the top of the DNS hierarchy. They do not normally provide the final IP address for yahoo.com. Instead, they tell the resolver where to find the name servers responsible for the relevant top-level domain.
For our example, the root server points the resolver toward the .com TLD name servers.
There are 13 named root server identities, conventionally labelled A through M. Each identity is served by multiple physical instances distributed around the world using anycast.
The important distinction is that root servers help the resolver navigate the DNS hierarchy; they are not a central database containing every website's IP address.
C. TLD name servers - locating the domain's authority
TLD stands for Top-Level Domain.
It refers to the final part of a domain name, such as:
.com.org.net.ke
In yahoo.com, the TLD is .com.
After receiving a referral from a root server, the resolver queries a .com TLD name server. That server identifies the authoritative name servers for yahoo.com.
The TLD server generally does not return Yahoo's final website IP address. It directs the resolver to the next level of the hierarchy.
Think of the root server as directing you to the correct department, while the TLD server directs you to the specific office responsible for the domain.
D. Authoritative name servers - the source of domain records
Authoritative name servers hold or serve the DNS records for a domain.
For yahoo.com, its authoritative name servers provide the records needed to answer queries about that domain.
Depending on the query, these records may include:
- A record: Maps a hostname to an IPv4 address.
- AAAA record: Maps a hostname to an IPv6 address.
- CNAME record: Identifies another canonical hostname.
- MX record: Identifies mail servers for a domain.
- NS record: Identifies the domain's authoritative name servers.
- TXT record: Stores text data used for purposes such as domain verification and email authentication.
For example, a query for an A record asks for the IPv4 address associated with a hostname.
The authoritative server might return an address, or it might return a CNAME that leads to another hostname requiring further resolution.
The exact records and addresses for Yahoo can change, so the values in this article are illustrative rather than a claim about Yahoo's current DNS configuration.
3. Following a request to yahoo.com
Let's put the components together.
Imagine that you open your browser and enter:
https://yahoo.com
Assume, for this example, that neither your device nor your recursive resolver has a usable cached answer.
Step 1: Your browser needs to resolve the hostname.
Your device checks available local caches and configured DNS resolution mechanisms. If it needs a new answer, it sends a query to its configured recursive resolver.
Step 2: The resolver queries a root server.
The root server responds with a referral identifying the name servers for .com.
Step 3: The resolver queries a .com TLD server.
The TLD server returns a referral to the authoritative name servers for yahoo.com.
Step 4: The resolver queries an authoritative name server.
The resolver asks for the relevant DNS record, such as the A or AAAA record for yahoo.com.
The authoritative server returns the requested information, possibly including a CNAME that requires another lookup.
Step 5: The resolver returns the answer.
Once the resolver has obtained the information needed to answer the query, it returns the result to your device and caches the applicable records according to their TTLs.
Step 6: The browser connects to the destination.
The browser uses the resolved address to establish a connection to the website. For HTTPS, this also involves TLS negotiation before the encrypted HTTP exchange can proceed.
DNS resolution helps locate the destination, but it does not itself load the webpage or establish the HTTPS connection.
4. DNS caching - why every request doesn't start from scratch
One of the most important things I learned is that DNS does not need to repeat the entire lookup process every time a domain is requested.
This is where DNS caching comes in.
Caching means temporarily storing DNS answers so they can be reused rather than retrieving them again from the original source.
DNS information can be cached at several levels, including:
- The browser, where supported.
- The operating system.
- A local network's DNS forwarder.
- The recursive DNS resolver.
The exact caching layers depend on the device, operating system, browser, and network configuration.
How caching works
Suppose you visit yahoo.com for the first time.
Your recursive resolver has no cached answer, so it follows the DNS hierarchy, obtains the relevant records, and returns the result.
Now imagine you visit the site again a short time later.
If the resolver still has a valid cached answer, it can return that answer immediately. It does not need to contact the root, TLD, and authoritative servers again.
This reduces DNS lookup latency, network traffic, and the workload on DNS infrastructure.
What is TTL?
DNS records commonly have a TTL (Time to Live), measured in seconds.
The TTL tells a caching resolver how long it may reuse a DNS record before it must treat that cached copy as expired.
For example, imagine an illustrative DNS record has a TTL of 300 seconds.
- At the time of retrieval, the record has a TTL of 300 seconds.
- After 100 seconds, a cache that tracks the record's age would have approximately 200 seconds remaining.
- After 300 seconds, the cached record expires and cannot be reused as a fresh answer.
The resolver will then need to obtain fresh information before answering from that record again, unless another applicable mechanism or cache supplies a valid answer.
Different DNS records can have different TTLs. An answer may also contain multiple records, each with its own caching lifetime.
Why TTL matters in DevOps
TTL becomes particularly important when infrastructure changes.
Imagine a service moves from one IP address to another during a deployment or migration.
If clients or recursive resolvers still hold the old DNS record, some requests may continue to use the previous address until the relevant cached information expires or is otherwise refreshed.
This is one reason DNS changes are not always visible everywhere immediately.
Lowering a record's TTL ahead of a planned migration can help reduce how long caches retain the old answer. However, lowering it does not invalidate copies that were already cached with a longer TTL.
DNS caching also does not guarantee that a service remains available. If a cached address points to an unhealthy server, clients may still attempt to connect to that server.
Understanding TTLs is therefore useful when managing deployments, traffic routing, service migrations, and incident response.
5. Recursive versus authoritative DNS
These two roles are easy to confuse, but they solve different problems.
| Recursive resolver | Authoritative name server |
|---|---|
| Finds answers on behalf of clients | Serves DNS records for domains it is authoritative for |
| May query other DNS servers | Provides authoritative answers or referrals as appropriate |
| Caches responses when permitted | Publishes or serves the domain's DNS data |
| Commonly used by devices to resolve hostnames | Commonly queried by recursive resolvers |
A recursive resolver is focused on obtaining an answer for the client. An authoritative server is responsible for supplying DNS information for its zone.
A single organization can operate both kinds of infrastructure, but the roles remain distinct.
6. What happens when DNS resolution fails?
Understanding the normal process is useful, but a DevOps engineer also needs to recognize what happens when it breaks.
Some common causes of DNS-related problems include:
- An incorrect or missing DNS record.
- Incorrect authoritative name server delegation.
- An unreachable or misconfigured recursive resolver.
- A stale cached record pointing to an old destination.
- DNS traffic being blocked by network rules.
- A CNAME chain that leads to a hostname that cannot be resolved.
- A domain's records not being configured as expected.
For example, if yahoo.com resolves successfully but the website does not load, DNS might not be the problem at all. The destination server, network connection, TLS configuration, or application could be failing instead.
This distinction is important during troubleshooting: resolving a hostname successfully does not prove that the application behind it is healthy.
On Linux, a few useful diagnostic commands are:
# Query DNS records using the system's configured resolver
getent ahosts yahoo.com
# Query an A record
dig yahoo.com A
# Query an AAAA record
dig yahoo.com AAAA
# Query the MX records
dig yahoo.com MX
# Trace the DNS delegation path
dig +trace yahoo.com
The dig +trace command is particularly useful for learning because it shows the delegation process from the root through the relevant TLD and authoritative servers, subject to the network environment.
These commands help separate DNS resolution issues from application-level failures.
7. What I took away from this lesson
Learning about DNS helped me understand that accessing a website involves more than simply entering a URL into a browser.
Behind a domain name is a distributed system of resolvers, root servers, TLD servers, authoritative name servers, and caching mechanisms. Each component has a specific responsibility, and together they allow users to locate services without needing to remember IP addresses.
The part that stood out to me most was DNS caching. It is a simple but important optimization that reduces repeated lookups, but it also explains why infrastructure changes may not take effect everywhere at the same time.
As I continue learning DevOps, I can see how DNS knowledge applies directly to deployment workflows, production troubleshooting, domain configuration, load balancing, and service availability.
The key takeaway: DNS is not a single server translating every domain into an IP address. It is a hierarchical, distributed lookup system, and caching helps make that system efficient.
Top comments (0)