扒一扒 DNS 的前世今生
今天給大家科普一下關于DNS的相關知識，講一講一個網址背后發生的一些故事。
簡單來說，DNS（域名系統）就是域名和各種數據之間的一個映射表。最常見的映射就是把像 chatgpt.com 這樣的域名轉換成電腦能懂的IP地址。
當你把 chatgpt.com 敲進瀏覽器時，DNS 就會出馬，找到并返回這個域名綁定的 IP 地址：
圖片
當然啦，這背后發生了很多事。在這篇文章里，我們就來扒一扒它到底是怎么運作的。
我希望這篇文章能比 ChatGPT 或者 DeepSeek 講得還好懂，要是連它們都能寫得比我好，那我就太失敗了！
好了，閑話少說，咱們開始吧。
DNS 誕生之前
在深入 DNS 之前，咱先看看它出現之前是啥情況。
在 80 年代現代互聯網出現之前，有個叫ARPAnet的玩意兒。它是當時第一個分組交換網絡，算是現代互聯網的老祖宗。
ARPAnet 用一個叫HOSTS.TXT的文件，把服務器的域名和網絡地址（也就是 IP 地址）對應起來。
這個文件大概長這樣：
# 官方 ARPANET 主機表 (hosts.txt)
# 格式：<IP 地址> <主機名> [別名] # [注釋]
10.0.0.6 mit-ai # MIT 人工智能實驗室
10.0.0.7 sri-nic # SRI 網絡信息中心
10.0.0.11 ucla-seismo # 加州大學洛杉磯分校 地震學系
10.0.0.13 berkeley # 加州大學伯克利分校
10.0.0.14 stanford # 斯坦福大學
# 別名 (可選項，跟在主機名后面)
10.0.0.6 mit mit-ai這個“主” HOSTS.TXT 文件就一份，由斯坦福研究所 (SRI) 獨家維護。這慢慢就出問題了，為啥呢？
- 流量和服務器壓力山大：所有設備都得找 SRI 的服務器查名字，SRI 服務器快被壓垮了。
- 名字撞車越來越頻繁：網絡變大了，大家想用的好名字就那些，沖突越來越多。
- 文件變得巨胖：文件大小漲到了 100-200KB。現在看這點數據不算啥，但在 80 年代的基礎設施條件下，這已經是個大瓶頸了。
這些問題可太要命了，直接催生了 DNS 的誕生。
DNS登場
DNS 架構
DNS (域名系統)最好理解成一個分布式的和層次化的系統。
啥意思呢？
- 分布式：意思是 DNS 運行在好多臺互相連接的服務器（也就是 DNS 服務器）上。
- 層次化：DNS 組織成一個樹狀結構，上面的服務器管著下面的服務器。等會兒講到 DNS 區域時再細說。
DNS 記錄
現在我們知道了，DNS 就是一堆服務器按樹狀結構組織起來，互相通信。那這些服務器存啥呢？
DNS 服務器存的就是DNS 記錄。看個例子：
# DNS 記錄結構
# 域名 TTL(秒) 類別 類型 數據
example.com. 3600 IN A 93.184.216.34
www.example.com. 3600 IN CNAME example.com.
example.com. 3600 IN MX 10 mail.example.com.
mail.example.com. 3600 IN A 93.184.216.50
example.com. 3600 IN TXT "hello world"來詳細掰扯掰扯每個字段是啥意思：
- 域名：就是互聯網上的域名，比如 chatgpt.com。注意結尾那個點 . 表示根域（通常可以省略）。
- TTL：生存時間（單位秒）。意思是這個記錄你能在本地緩存多久，過期了就得去問權威服務器要新的。
- 類別：這玩意兒基本總是IN，代表“互聯網” (Internet)。還有別的類，像CH或HS，但現在基本不用了。
- 類型：代表這條記錄存的是哪類數據。最常見的類型有：
A：代表一個IPv4 地址。
AAAA：代表一個IPv6 地址。
CNAME：意思是規范名稱，就是給另一個域名起個別名。
MX：郵件交換器，指定誰來收這個域名的郵件（后面跟優先級，數字越小越優先）。
TXT：文本記錄，可以存任意文本（比如驗證信息、安全策略啥的）。
- 數據：你要查的那個信息的真身。具體是啥完全取決于類型字段。
DNS 區域
還記得我們說 DNS 是個大樹嗎？
那么，一個 DNS 區域就可以代表整棵樹、樹的一個分支、或者樹里的一個節點。
在下面的示意圖里，我圈出了兩個分支，標為區域1和區域2。不過區域怎么劃分其實挺隨意的。
圖片
關鍵點在于：位于一個區域根部的那個 DNS 服務器，負責管理它下面的所有服務器。比如，example.com 這個服務器就管著 hello 和 world（如果它們是子域的話）。
DNS 服務器
“DNS 服務器”這個詞用得很寬泛，這也是我學 DNS 時最暈乎的地方之一。
簡單說，任何運行 DNS 軟件的服務器都可以叫 DNS 服務器。但有四種核心角色你必須知道：
- 權威域名服務器：這些服務器存著它們負責的DNS 區域里所有域名的官方 DNS 記錄。比如 .com 的權威服務器就存著所有以 .com 結尾網站的記錄。
- 遞歸解析器：一個專門幫客戶（比如你的電腦）查找 DNS 信息的程序，還會把結果緩存起來。比如客戶說“我要訪問 www.example.com”，遞歸解析器就把復雜的查詢過程全包了，最后直接給你返回 example.com 的正確 IPv4 地址（A 記錄）。你的路由器或 ISP（像電信、聯通）提供的 DNS 服務器通常就干這個活。
- 緩存服務器：專門用來存之前查過的 DNS 結果，這樣下次再問就能飛快地給答案。
- 轉發器：它自己不去查，而是把收到的 DNS 查詢請求 轉給另一個能查的服務器（通常就是個遞歸解析器）去處理。
一臺物理上的 DNS 服務器可以同時干好幾樣活。比如，一個遞歸解析器通常也自帶緩存功能（也就是緩存服務器）。
DNS 查詢實例
術語講夠了，讓我們看個動圖（腦補一下）！看看這一切是怎么配合工作的，舉個栗子??：一個客戶端第一次查詢 hello.world.com 的 IP 地址（A 記錄）。
圖片
請求內容是：A hello.world.com? (意思就是：hello.world.com 的 IP 是啥？)
注意：存根解析器（Stub Resolver）不算真正的 DNS 服務器，它就是你電腦操作系統里一個簡單的 DNS 客戶端，負責跟你配置的 DNS 服務器（通常是路由器或 ISP 的）對話。路由器這時通常就扮演轉發器的角色。
接下來，就要進行遞歸 DNS 查詢了。過程大概是這樣的：
- 客戶端問路由器/本地DNS：“嘿，hello.world.com 的 IP 是啥？” (本地沒緩存)。
- 本地DNS（遞歸解析器）開始干活：
- 先看看自己緩存里有沒有，沒有。
- 跑去問根域名服務器：“.com 該找誰管啊？”
- 根服務器回復：“.com 的事歸這些 TLD 服務器（頂級域服務器）管，地址是 X.X.X.X”。
- 問 .com TLD 服務器：“world.com 該找誰管啊？”
- .com TLD 服務器回復：“world.com 歸這些權威服務器管，地址是 Y.Y.Y.Y”。
- 問 world.com 權威服務器：“hello.world.com 的 IP 是啥？”
- world.com 的權威服務器回復：“在這兒呢，hello.world.com 的 A 記錄是143.54.1.8”。
- 結果返回與緩存：
- 遞歸解析器拿到最終答案 143.54.1.88，開心地把它返回給客戶端（一路經過路由器）。
- 這個結果會一路被緩存：ISP 的解析器會緩存它，你的路由器（如果支持）也可能會緩存，你的電腦操作系統也會緩存。緩存多久？看記錄的 TTL 值，通常幾小時到幾天不等（比如 1 到 72 小時）。
- 連接建立：客戶端瀏覽器拿到 IP 地址 143.54.1.88，終于可以向這個地址發送 HTTP 請求加載網頁了。
圖片
結語
DNS 這玩意兒挺繞的，倒不是因為它本身多難，而是因為要搞懂的東西實在有點多。
即使有了這些概念解釋和實例演示，我們也只是掀開了 DNS 世界的一角。它在現實世界中能干的事和帶來的影響，遠比我們這里講的要豐富和深遠得多。
