When you use a browser, the DNS resolution process will automatically start after you enter a website. This is a sophisticated distributed query system. This process can be broken down into 8 key steps. For example, we will use the example of accessing "www.example.com" to share.

First, the local cache query will start. The computer will first check the cache records in three places: the browser cache Chrome/Firefox will save the domain name resolution results of the most recently visited domain name; the system cache: the DNS Client service of Windows or the mDNSResponder of macOS will store the resolution records. In the Hosts file, check whether there is a manually configured domain name mapping in the system file. If the cache hits and has not expired (based on the TTL value), the result is returned directly, and the whole process is usually completed within 1 millisecond.

Then the router query starts. When there is no local cache, the request is sent to the router in the home or office. Modern routers have built-in DNS proxy functions and maintain their own cache. The default cache time for common router brands is 60-300 seconds, and enterprise-level routers may cache longer.

The third step is to query the ISP DNS server. If the router also has no record, the request will be transmitted to the DNS server of the network service provider (China Telecom, China Unicom, etc.). These servers are deployed at provincial network nodes and use Anycast technology to ensure local response. The characteristics of operator DNS are: aggressive caching strategy (may ignore TTL); may embed advertisements or hijack error pages; response speed is usually 10-50 milliseconds.

The fourth step is root domain name server query. When all caches miss, real recursive query begins. The ISP's DNS server will start querying from the root domain name server (13 groups worldwide, numbered A-M). The root server does not directly answer the domain name resolution, but returns the address of the top-level domain (TLD) server. For example, query the NS record of ".com":

;; AUTHORITY SECTION:
com.            172800  IN  NS  a.gtld-servers.net.
com. 172800  IN  NS  b.gtld-servers.net.

The fifth step is top-level domain server query. Then query the authoritative DNS server of "example.com" to the .com domain name server. The global top-level domain server is managed by ICANN and is deployed in a distributed manner:

Generic top-level domain (gTLD) .com/.net/.org, etc.; Country code top-level domain (ccTLD) .cn/.jp, etc.; New generic top-level domain .app/.blog, etc. The response example is as follows:

example.com.    172800  IN  NS  ns1.example.com.
example.com.    172800  IN  NS  ns2.example.com.

Step 6 Authoritative DNS server query. Finally, a request is made to the authoritative DNS server specified when the domain name is registered. There may be several situations here: self-built DNS, BIND/Windows DNS server managed by the enterprise itself; resolution service provided by some enterprises of managed DNS; resolution provided by default by the registrar DNS.

The authoritative server returns the final A record (IPv4) or AAAA record (IPv6):

www.example.com. 300  IN  A  192.0.2.1

Step 7 Result cache and return. After obtaining the final IP, the ISP's DNS server will cache the results level by level. The cache time will be set according to the TTL value (usually 300-86400 seconds), and the result will be returned to the client through UDP port 53, and the client will also cache the result.

Step 8: Establish an actual connection. After the browser obtains the IP, it starts the TCP three-way handshake:

Send a SYN packet to port 80/443 of 192.0.2.1, wait for the server's SYN-ACK response, and reply ACK to confirm the connection.

There will be some common problems and optimizations in the DNS resolution process. For example, if the resolution is slow, check:

dig +trace www.example.com # View the complete resolution path

Force cache refresh:

sudo dscacheutil -flushcache # macOS
ipconfig /flushdns         # Windows

Select the best DNS:

nslookup -type=NS example.com

Security-related mechanisms include DNSSEC verification, which is to prevent DNS spoofing:

dig +dnssec www.example.com

Encrypted query in DNS over HTTPS:

curl -H 'accept: application/dns-json' \
'https://cloudflare-dns.com/dns-query?name=example.com&type=A'

Enterprise-level application scenarios include private DNS deployment:

# BIND configuration example
zone "example.com" {
type master;
file "/etc/bind/db.example.com";
};
Also intelligent resolution:
# Return different results based on source IP
view "internal" {
match-clients { 192.168.0.0/16; };
zone "example.com" {
file "/etc/bind/internal.db";
};
};

Special processing for mobile networks will increase similar to 4G/5G networks, such as operator DNS hijacking detection, EDNS Client Subnet delivery, and local P-CSCF DNS proxy. Emerging technology impacts such as AAAA record query for IPv6, QUIC protocol optimization of DNS, and blockchain domain name system (such as ENS).

The entire DNS resolution process is usually completed within 100-300 milliseconds. After more than 30 years of evolution, this system handles more than one trillion queries per day and remains stable. Understanding its working principle can help diagnose network problems, optimize access speed, and provide basic support for architecture design. In actual applications, it is recommended to regularly check DNS configuration, monitor resolution delay, and consider deploying enhanced solutions such as HTTP DNS in key business scenarios.