The complete process of domain name resolution: what happens from entering a URL to displaying a webpage.

　　Typing www.example.com into your browser's address bar and pressing Enter, the webpage appears on the screen—a process so fast you can barely feel the delay. But in those few hundred milliseconds, a multitude of devices on the internet work together to complete a series of intricate operations. Domain name resolution is the most crucial link in this chain; without it, the browser wouldn't know where to find the data you need.

　　Why is Domain Name Resolution Necessary?

　　The underlying layer of network communication relies on IP addresses. IPv4 is a 32-bit number, such as 203.0.113.5, while IPv6 is even longer, a string of alphanumeric characters. Humans can't remember these, especially when visiting dozens of different websites. The Domain Name System (DNS) is a distributed database designed to solve this problem—it translates human-readable domain names into machine-readable IP addresses.

　　This process is called domain name resolution, also known as a DNS lookup.

　　The browser first checks its own cache.

　　After pressing Enter, the first thing the browser does isn't to send a network request, but to check its local cache. Modern browsers have built-in DNS caching modules that record previously queried domain names and their corresponding IP addresses, as well as the remaining lifespan of these records—determined by the domain's Time-To-Live (TTL).

　　If a record is found in the cache and the TTL hasn't expired, the browser directly uses this IP to establish a TCP connection, ending the entire resolution process. This step occurs in memory and is extremely fast, completed within microseconds.

　　If the record isn't in the cache, or has expired, the browser delegates the query to the operating system.

　　The Operating System's Hosts File and Cache

　　Upon receiving a query request, the operating system first checks its local cache. Linux and Windows both have system-level DNS caching services. If the cache is hit, the result is returned directly to the browser.

　　If the system cache also fails to find the record, the operating system searches the local hosts file. The path to this file varies across different systems: on Linux and macOS, it's located at `/etc/hosts`, and on Windows, it's at `C:\Windows\System32\drivers\etc\hosts`.

　　The hosts file is a local static mapping table with very high priority. Many developers add temporary mappings to this file during local testing, such as pointing www.example.com to 127.0.0.1. If a matching record exists in the hosts file, the operating system returns the result directly without sending any further network requests.

　　Recursive Query: Sending a Request to the Local DNS Server

　　If the above three layers of caching fail, the operating system sends a query request to the local DNS server specified in the network configuration. This local DNS server is usually provided by your internet service provider, but can also be manually changed to a public DNS.

　　From this step onwards, the actual network request occurs. The DNS query message sent by the operating system uses the UDP protocol, with the target port being 53.

　　Here is an important concept called recursive query. The request sent by the operating system to the local DNS server requires the server to provide the final query result. If it doesn't know the answer itself, it must query other DNS servers until it obtains the result before returning it to you.

　　Iterative Query: Local DNS Server Proceeds Layer by Layer

　　When the local DNS server receives a query request, it has its own cache and will first check it. If the query is not found, it begins an iterative query—searching down layer by layer, from the root servers to the top-level domain servers and then to the authoritative servers.

　　Step 1: Querying the Root Servers

　　The local DNS server first queries any one of the 13 groups of root servers. The root servers are the highest level in the global DNS system; they do not store specific domain name records, but they know the addresses of all top-level domain servers.

　　When a root server receives a query for www.example.com, it returns the server addresses corresponding to the top-level domain based on the domain name's suffix—a list of top-level domain servers for .com.

　　Step 2: Querying the Top-Level Domain Servers

　　After obtaining the addresses returned by the root servers, the local DNS server then accesses the top-level domain servers for .com. The top-level domain servers also do not store specific domain name records, but they know which authoritative server is behind each top-level domain. They return the address of the authoritative DNS server corresponding to example.com.

　　Step 3: Query the Authoritative DNS Server

　　After obtaining the address of the authoritative DNS server, the final step for the local DNS server is to send a query to it. The authoritative DNS server for example.com stores the actual data of all records under this domain, including the A record or CNAME record corresponding to www.example.com.

　　Upon receiving the query, the authoritative DNS server searches its own zone file for the IP address corresponding to www.example.com and then returns this result to the local DNS server.

　　Cache and Return

　　After obtaining the final IP address, the local DNS server first stores this result in its cache and sets an expiration time based on the record's TTL value. Then, it returns the IP address to the operating system, which in turn returns it to the browser.

　　Once the browser receives the IP address, the DNS query process ends. It then begins establishing a TCP connection, sending an HTTP request, receiving response data, and rendering the page.

　　Difference between Iterative and Recursive Queries

　　The entire process involves two query modes. The query between the client and the local DNS server is recursive—the client only needs to query once and wait for the result. The local DNS server uses iterative queries to reach the root server, top-level domain server, and authoritative server—each query only retrieves the address of the next hop, requiring further follow-up queries.

　　This design is intentional. If the burden of iteration were placed entirely on the root server, it would be overwhelmed long ago. Iterative queries distribute the workload across servers at each level, with each level responsible for its own small area.

　　DNS Record Types

　　The A record mentioned earlier is just one basic category of DNS record types. Besides A records, there are several other common record types:

　　AAAA Record: Resolves a domain name to an IPv6 address. It functions the same as an A record, but is specific to IPv6.

　　CNAME Record: Resolves a domain name to another domain name. For example, www.example.com might have a CNAME record pointing to cdn.example.net, with the IP address ultimately provided by the latter domain.

　　MX Record: Specifies the address of a mail server used for sending and receiving emails.

　　NS Record: Specifies the authoritative DNS server for a domain name.

　　A typical query's complete message path:

　　The above process can be visualized as the following path:

　　Browser cache → Operating system cache → hosts file → Local DNS server cache → Root server → Top-level domain server → Authoritative server → Local DNS server cache → Operating system cache → Browser cache

　　Each layer of caching exists to speed up the process. Root servers and top-level domain servers generally do not directly bear the query pressure from ordinary users; most queries are already cached and hit at the local DNS server level.

　　Problems that may be encountered during domain name resolution:

　　Domain name resolution is not 100% successful. Common problems include:

　　Local DNS server failure or response timeout: If the DNS server provided by your ISP is down or slow to respond, the entire resolution process will stall. Changing your local DNS to 8.8.8.8 or 114.114.114.114 often works.

　　Authority server misconfiguration: For example, if the domain's NS record points to the wrong server address, or if the A record on the authoritative server is incorrect, the local DNS server will receive an incorrect IP address.

　　Cache pollution or DNS hijacking: In some network environments, the ISP's DNS server may return incorrect IP addresses, redirecting users to advertising pages. Using DNS over HTTPS or DNSSEC can help protect against this.

　　Inappropriate TTL setting: If the TTL is set too short, the access pressure on the authoritative server will increase, and the resolution latency on the user's end will also increase. If it is set too long, the domain will face a long waiting time when changing IP addresses.

　　Inappropriate TTL setting: In summary, the complete domain name resolution process, from entering a URL to obtaining an IP address, involves multiple nodes, including the browser, operating system, local DNS server, root server, top-level domain server, and authoritative server. Each layer relies on caching for acceleration, and each layer has its own scope of query responsibility. This system, designed in the 1980s, continues to operate today, supporting the addressing needs of the entire internet. The next time you enter a URL in your browser and see the page load instantly, consider this: behind the scenes, these six layers of nodes have already completed a globally distributed query for you within a few hundred milliseconds.