What is domain name resolution? A simple explanation of how a domain name is turned into an IP address!
You type www.example.com into your browser, press Enter, and the Baidu homepage appears in less than a second. But behind this, there's a process you barely notice, yet it's extremely crucial: domain name resolution.
Simply put, domain name resolution translates a human-readable string of letters like "www.example.com" into a machine-readable IP address like "110.242.68.66". Without this process, you'd have to memorize a string of numbers every time you go online—and the length of an IPv6 address is something even professional system administrators probably couldn't remember.
This article won't delve into deep technical details, but it will try to explain the most critical parts of the entire chain clearly. After reading it, you'll understand what actually happens when you enter a website address, why resolution can sometimes be slow, why DNS hijacking occurs, and what those seemingly mysterious TTL, recursive queries, and authoritative servers really mean.
Why is domain name resolution necessary?
Let's answer a very basic question first: Why can't we access websites directly using IP addresses?
Of course we can. You can open the Baidu homepage by typing 110.242.68.66 into your browser's address bar. The problem is, IP addresses are not human-friendly. There are billions of IP addresses on the internet; humans simply cannot remember them all, let alone distinguish which IP corresponds to which website.
Domain names are for human use. Meaningful word combinations like example.com are easy to remember at a glance. But machines only recognize IP addresses; they don't care what the domain name is, only which specific network interface the data packet is sent to. Therefore, an intermediate layer is needed to translate; this translation process is domain name resolution.
You can think of a domain name as a contact list: you save the name "Zhang San," but what you actually dial is an 11-digit number starting with 138. Domain name resolution is like looking up a contact in your contact list.
The complete process of domain name resolution
From the time you press Enter to the page loading, domain name resolution only takes up tens to hundreds of milliseconds. But within those tens of milliseconds, at least four to five stages of collaboration occur.
Step 1: Browser Cache
Browsers remember the domain names and IP addresses of websites you've recently visited. This cache is short-lived, usually only a few minutes to an hour, but it's very useful—when you repeatedly visit the same website, the browser doesn't need to query the DNS server; it retrieves the IP directly from memory.
In Chrome, you can access chrome://net-internals/#dns to view the current browser's DNS cache.
Step 2: Operating System Cache (hosts file)
If the browser doesn't find the IP in its cache, it will query the operating system. The operating system also has a DNS cache, which stores system-level historical DNS records. On Windows, you can use `ipconfig /displaydns` to view it; on Linux and Mac, use `scutil --dns`.
Before the operating system cache, there's a higher-priority source: the hosts file. This file is located at `/etc/hosts` (Linux/Mac) or `C:\Windows\System32\drivers\etc\hosts` (Windows). If you manually specify the IP address corresponding to a domain name in this file, the system will directly accept it without further queries.
Many developers use their hosts file to point test domains to 127.0.0.1 when debugging locally. This file is also a way for some malware to hijack DNS, for example, pointing example.com to a phishing website.
Step 3: Recursive DNS Server (Local DNS)
If the operating system's cache doesn't find it, it will query a recursive DNS server. This server is usually automatically obtained when you connect to the internet, such as the DNS address your home router gets from your ISP. Common recursive DNS servers include 114.114.114.114, 8.8.8.8, and 1.1.1.1.
The recursive DNS server will complete the entire query process for you. Its logic is: first, it checks its own cache; if it has a record for www.example.com, it returns the result directly. If not, it queries the root name servers.
Step 4: Root Name Servers
Since the recursive DNS server doesn't know the IP address of www.example.com, it will first query the root name servers. There are 13 root servers globally, distributed around the world and managed by ICANN. They do not store the IP addresses of any specific domain names; they only answer one question: Who manages the .com top-level domain?
The root servers tell the recursive DNS: The information for the .com domain is with a certain authoritative server; go to that server.
Step 5: Top-Level Name Servers
After receiving the instructions from the root servers, the recursive DNS looks for the authoritative servers for .com. The .com servers also do not store specific information about example.com; they only tell the recursive DNS: Which are the authoritative servers for the example.com domain?
Step 6: Authoritative Name Servers
The recursive DNS continues its query and finds the authoritative server for example.com. This server is where all the domain name resolution records for Baidu are actually stored. It tells the recursive DNS: The A record for www.example.com points to a certain IP address.
At this point, the recursive DNS finally obtains the IP address corresponding to www.example.com, and then returns this result to your computer, while also storing it in its own cache. The next time someone queries the same domain name, there's no need to run a complete query again.
The entire chain can be simplified as follows: Browser cache → Operating system cache/hosts → Recursive DNS → Root server → Top-level domain server → Authoritative server → Return result.
What do record types mean?
Domain name resolution doesn't just involve the "domain → IP" mapping; there are several record types, each responsible for different functions.
A Record: The most commonly used, resolving a domain name to an IPv4 address. www.example.com → 192.0.2.1.
AAAA Record: The IPv6 version of the A record, resolving a domain name to an IPv6 address.
CNAME Record: An alias record. Points one domain name to another, for example, pointing blog.example.com to example.com. Accessing blog.example.com then retrieves the IP address of example.com. The advantage of CNAME is that if the IP address of example.com changes, all CNAME records pointing to it automatically update, without needing to be individually modified.
MX Record: A mail exchange record, telling the mail system which server should be used to send emails for this domain. Each domain name has its own MX record, pointing to the mail server responsible for receiving emails from that domain.
NS Record: This is an authoritative server record that specifies which DNS authoritative servers are for this domain. Modifying an NS record means transferring the domain's resolution authority to another service provider.
TXT Record: This is a text record commonly used for domain ownership verification, SPF anti-spam configuration, etc. For example, if you want to configure Google Workspace or a third-party email service in your domain, you usually need to add a TXT record for verification.
What is TTL? Why don't changes to domain name resolution take effect immediately?
People often ask, "I changed my domain name resolution, but why is it still showing the old IP after so long?" This is because TTL is at work.
TTL stands for Time To Live, and it's measured in seconds. It tells the recursive DNS and various nodes how long this record is valid. For example, setting the TTL to 600 seconds means that this DNS record is kept in the cache for 10 minutes. If a query comes within 10 minutes, the cached result will be used directly, without querying the authoritative servers.
Therefore, when you change the DNS records on the authoritative server, the recursive DNS cache still holds the old value. It won't fetch the new record until the TTL expires. A longer TTL results in a higher cache hit rate and faster resolution, but the changes take longer to take effect. A shorter TTL takes effect quickly, but increases the query pressure on the authoritative server.
If you plan to migrate your domain or change your server IP, it's best to reduce the TTL a day in advance (e.g., to 300 seconds). When the switch occurs, the old records will expire quickly, allowing users to access the new server faster.
The Difference Between Recursive and Iterative Queries
These two concepts are often confused. Here's a simple distinction:
Recursive Queries: You only query once. The DNS server handles all the steps and gives you the result. You only care about the result, not the process. The interaction between the browser and the recursive DNS is a recursive query.
Iterative Queries: You only query one step at a time. Once the query is found, it returns the next step, and you continue querying. Recursive DNS queries, moving between the root server, top-level domain server, and authoritative server, are iterative queries.
You can think of it this way: Recursion is like telling a courier, "Deliver this package to Zhang San," and the courier handles the entire process; you don't need to know which transit points the package passed through. Iteration is like driving to transit point A and asking, "Where is this package?" A tells you, "At transit point B," you go to B, B tells you, "At transit point C," and so on, until you receive the package.
In a practical DNS system, the client typically only performs recursive queries, while the recursive server performs a series of iterative queries for the client.
Common DNS Problems and Solutions
Slow DNS Resolution: The most common cause is slow response from the recursive DNS server, or the DNS server you chose being too far away. Switching to a public DNS server usually improves this.
DNS Hijacking: ISPs or intermediary devices tamper with DNS responses, redirecting the domain name you want to access to a different IP address. A typical symptom is entering the correct URL but being redirected to an advertising page or search engine navigation page. Solutions: Enable domain name verification using DNSSEC, or switch to encrypted DNS protocols such as DoH and DoT to prevent man-in-the-middle attacks and tampering.
Websites can be pinged but cannot be opened in the browser: This usually indicates an incorrect mapping in the local hosts file or that the browser is caching incorrect DNS results. Clearing the browser cache, checking the hosts file, and refreshing the DNS cache should resolve the issue.
In summary: Domain name resolution is essentially a distributed query system. Its ingenious design lies in its hierarchical management and tiered authorization. Root servers only manage top-level domains, top-level domains only manage their own second-level domains, and each domain's authoritative server only manages its own resolution records. No single server needs to store all domain name information on the internet; each manages its own area, and global queries are completed through mutual guidance. When you type a domain name in your browser, it may involve the collaboration of a dozen network nodes, but the entire process usually takes no more than 200 milliseconds. You don't feel it, but it's constantly running. This is how internet infrastructure should be—the more important something is, the less you should be aware of its existence.
CN
EN