Operations 17 min read

How Does a Browser Find a Website? DNS, TCP Handshake, and Server Setup Explained

This article walks through the complete process from entering a URL in a browser to rendering a webpage, covering client DNS resolution, TCP three‑way handshake, HTTP request/response flow, DNS hierarchy, key terminology, using dig for troubleshooting, and step‑by‑step guides to build your own DNS server with BIND or dnsmasq.

Raymond Ops
Raymond Ops
Raymond Ops
How Does a Browser Find a Website? DNS, TCP Handshake, and Server Setup Explained

What Happens After You Type a URL in the Browser

This classic question reveals the depth of knowledge required to understand website access, ranging from basic concepts for beginners to detailed processes for advanced users.

1. Client Access Flow

0. Client ensures it can reach the Internet.
1. Browser inputs URL (e.g., www.yuchaoit.cn) and presses Enter.
2. Local DNS lookup resolves the domain to an IP address.
3. Client initiates a TCP three‑way handshake with the server IP.
4. After TCP is established, the browser sends an HTTP request (may involve multiple requests).
5. Server receives the request, parses it, and sends back an HTTP response (may involve multiple responses).
6. Browser receives the response, parses the data, and renders the page on the screen.
7. Client closes the connection with a TCP four‑way handshake.

2. Key Technical Terms

1. Domain name
2. DNS resolution
3. TCP/IP three‑way handshake
4. TCP/IP four‑way termination
5. HTTP request
6. HTTP response

3. DNS Domain Structure

Domain names use a hierarchical tree structure. Each label is separated by a dot, forming root, top‑level domain (TLD), second‑level domain, and sub‑domains.

DNS hierarchy diagram
DNS hierarchy diagram

Root Domain

The root (.) is served by 13 root servers worldwide, with one primary root server in the United States and 12 secondary servers distributed across the US, Europe, and Asia.

Top‑Level Domain (TLD)

The last part of a domain name (e.g., .cn, .com) is the TLD.

Second‑Level and Sub‑Domains

Examples: in http://yuchaoit.cn, "yuchaoit" is the second‑level domain; any further labels are sub‑domains.

4. DNS Server Hierarchy and Resolution Process

DNS resolution flow diagram
DNS resolution flow diagram

The resolution steps are:

1. Browser checks the local hosts file for a static mapping.
2. If not found, it queries the configured local DNS server (often provided by the ISP).
3. The local DNS server checks its cache; if missing, it queries root servers.
4. Root servers return the address of the appropriate TLD server.
5. The TLD server returns the address of the authoritative server for the domain.
6. The authoritative server returns the final IP address, which is cached locally.

5. Important DNS Terms

Recursive query : The DNS server performs the full lookup on behalf of the client, following the chain from root to authoritative server.

Iterative query : The DNS server returns a referral to the next server, and the client continues the lookup.

DNS cache : Local storage of domain‑to‑IP mappings to speed up subsequent lookups.

TTL (Time To Live) : The duration a cached record remains valid before it must be refreshed.

6. Using dig to Trace DNS Resolution

# yum install bind-utils -y
# dig +trace www.yuchaoit.cn

The dig command shows each step of the resolution, from root servers down to the final A record.

7. Building Your Own DNS Server with BIND

Install BIND and bind‑utils, configure /etc/named.conf, create zone files, and start the service.

# yum install bind bind-utils -y
# systemctl start named
# netstat -tunlp | grep named

Example zone configuration for laoliulinux.cn:

zone "laoliulinux.cn" IN {
    type master;
    file "laoliulinux.cn.zone";
    allow-update { none; };
};

Sample .zone file:

$TTL 1D
@   IN  SOA @ rname.invalid. (
        0      ; serial
        1D     ; refresh
        1H     ; retry
        1W     ; expire
        3H )   ; minimum
    NS  @
    A   172.16.1.61
    AAAA    ::1

www     A   172.16.1.61
linux   A   172.16.1.61

8. Configuring Clients to Use the Custom DNS

Update /etc/resolv.conf on client machines to point to the new DNS server (e.g., nameserver 172.16.1.61).

9. Lightweight Alternative: dnsmasq

Stop BIND, install dnsmasq, and configure it to forward queries to upstream servers while providing local static records.

# yum install dnsmasq -y
# vim /etc/dnsmasq.conf
# echo "nameserver 223.5.5.5" > /etc/resolv.dnsmasq.conf
# cat > /etc/hosts.dnsmasq.conf <<EOF
172.16.1.61 master-61
172.16.1.5 slb-5
172.16.1.6 slb-6
172.16.1.7 web-7
... (other hosts)
EOF
# systemctl start dnsmasq

Clients then set nameserver 172.16.1.61 in their /etc/resolv.conf to use dnsmasq.

Original Source

Signed-in readers can open the original source through BestHub's protected redirect.

Sign in to view source
Republication Notice

This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactadmin@besthub.devand we will review it promptly.

DNSnetwork operationsBINDDomain Name SystemTCP handshakedigdnsmasq
Raymond Ops
Written by

Raymond Ops

Linux ops automation, cloud-native, Kubernetes, SRE, DevOps, Python, Golang and related tech discussions.

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.