一步一步解析一個名稱

那個你從未看見被提出的問題

在前兩篇裡，你學到了 DNS 為什麼存在——名稱對人類友善，位址對路由器友善——以及它的名稱如何被組織成一棵樹：頂端是根，底下是像 com 與 org 這樣的頂級網域，再底下則是替每個區域保管真正答案的授權伺服器。那給了你一張地形圖。本篇談的是這趟旅程：當你輸入 www.example.com 時，究竟是誰走過那棵樹、以什麼順序去走，最後帶回一個像 93.184.216.34 的位址？

驚奇之處在這裡。你的筆電、你的手機、瀏覽器本身——它們沒有一個會去走那棵樹。它們太小、也太健忘，不可能認得整棵樹。取而代之，它們把整個問題交給一位幫手，然後等一個整齊的答案回來。那位幫手就是 解析器（常被稱為遞迴解析器），而看懂你與它之間的分工，正是解開本篇其餘一切的那把鑰匙。

遞迴對上迭代：兩種發問方式

問問題有兩種方式，而 DNS 兩種都用——在同一次查詢的不同環節用。第一種是 遞迴查詢：「去替我把完整答案拿回來；沒拿到之前別回來。」這就是你對你的解析器所做的事。你向它要 www.example.com，你期待換回一個完成的位址，而不是一條提示或一次轉介。這就像請一位勤勉的圖書館員去查一個事實，並信任他會去做任何必要的挖掘，而你就在櫃台旁等。

第二種是 迭代查詢：「告訴我你所知道的，哪怕只是『下一步該問誰』。」這就是解析器對樹上那些伺服器所做的事。當解析器去問一台根伺服器 www.example.com 時，根並不知道答案，也不會替你去找。它只是回覆，意思大致是：「我不知道，但這些是負責 com 的伺服器——去問它們吧。」這樣的回覆叫做轉介。解析器接下這條提示，往樹下走一步，再問一次。

於是分工乾淨俐落。你發出一個遞迴請求，然後就放鬆。解析器為了履行那個請求，會代你跑一連串有耐心的迭代查詢——先根、再頂級網域、再授權伺服器——每一次交回的都不是答案，而是「下一個該看的地方」的指標。解析器之所以跑這些腿力活，正是為了讓你的裝置不必跑。就是這一個設計選擇，讓一支小小的手機能解析地球另一端的名稱，而完全不必認得這棵樹長什麼樣子。

追蹤一次查詢，從根到授權

讓我們一路跟著一次全新的查詢往下走，先假設解析器手上還沒有任何有用的記憶（這個假設我們待會就會修正，因為在真實生活裡，記憶會改變一切）。請看名稱 www.example.com 是如何由右往左讀的，一次讀一個標籤，而每一台伺服器都把解析器又往答案推近一步。

你的瀏覽器去問作業系統，作業系統再去問你所設定的解析器，提出一個遞迴問題：「www.example.com 的位址是什麼？」然後你就等著。
解析器去問一台根伺服器。根讀取最右邊的標籤，並以一次轉介回覆：「凡是以 com 結尾的，去問這些頂級網域名稱伺服器。」它會給出那些伺服器的名稱與位址（這就是你下一篇會遇到的 NS 資訊）。
解析器去問其中一台 com 頂級網域伺服器。它同樣不知道最終位址，但它知道誰在營運 example.com，於是再把解析器往下轉介：「至於 example.com，去問這些授權名稱伺服器。」
解析器去問一台 example.com 的授權伺服器。這台伺服器真的保管著該區域的紀錄，於是它終於給出一個真正的答案：「www.example.com 是 93.184.216.34。」這就是這趟攀爬的底部。
解析器把那個完成的位址交回給你的作業系統，作業系統再交給你的瀏覽器。直到此刻，你的瀏覽器才會對 93.184.216.34 開啟一條連線。整趟走樹的過程，對你而言都是隱形的。

  YOU --(recursive: "www.example.com?")--> RESOLVER

  RESOLVER  --iterative-->  ROOT server
            <--referral---  "ask the .com servers"

  RESOLVER  --iterative-->  .com TLD server
            <--referral---  "ask example.com's servers"

  RESOLVER  --iterative-->  example.com AUTHORITATIVE
            <--answer-----  "www.example.com = 93.184.216.34"

  RESOLVER --(answer: 93.184.216.34)--> YOU

你發出一個遞迴請求；解析器跑了一連串迭代轉介。樹上每一台伺服器，說的不是「去那邊問」，就是在底部說「位址在這裡」。

為什麼這沒有把根伺服器燒熔

你對那段追蹤的第一個誠實反應，應該是警覺。每分鐘都發生數十億次查詢。如果每一次真的都從去煩一台根伺服器開始，那根就會是史上最忙、最不堪負荷的機器。它之所以沒有如此，靠的是「讓 DNS 在行星級規模上運作」這件事裡最重要的單一想法：快取。解析器會把它學到的每一個答案、每一次轉介都記住一陣子，並重複使用它們，而不是再問一次。

再走一次那段追蹤，但這次把你當成當天的第二位訪客。解析器早已從稍早某人那裡學到「哪些伺服器營運 com」——於是它完全跳過根，直奔 com 頂級網域。如果它同時還記得 example.com 的授權伺服器，那它連頂級網域也跳過。而如果它在幾分鐘前才把那個最終位址本身快取下來，它根本不必出門，就能立刻回答你。那種冰冷、完整、從根到授權的走樹，是罕見情況；溫熱、局部的查詢，才是壓倒性的常態。（每一條事實可以被快取多久，由一個叫做 TTL 的數值掌管——那正是下一篇的整個主題，所以我們把這個計時器留在那裡。）

你掌握了什麼，以及要當心什麼

退一步看，整套機制濃縮成一句話：你向你的解析器問一個遞迴問題，解析器透過沿著樹往下跑迭代查詢來回答它——先根、再頂級網域、再授權——而快取加上任播，使這一切永遠不會變慢、也不會集中於一處。這真的就是「一個名稱如何變成一個位址」的絕大部分了。其餘的篇章只是補上細節：授權伺服器能回傳哪些種類的紀錄、答案能活多久，以及如何讓整段對話變得可信。

在你繼續往上爬之前，有兩點誠實的提醒。第一，這一切預設都不安全。那些轉介與最終答案，是以明文、未簽署、未加密的訊息抵達的——通常為了速度而走 UDP——所以路徑上任何人都讀得到你查了哪些名稱，而一個位置得當的攻擊者，甚至可能偽造一個回覆、把你送到錯誤的位址。解析器相信別人告訴它的話。補上那道缺口，正是最後一篇談 DNSSEC 與加密查詢的目的；現在，你只要先記住：你剛學會的這套系統，又快又能擴展，但很輕信。

第二，別把解析器跟授權伺服器搞混。它們聽起來相似，扮演的角色卻相反：授權伺服器是擁有某個區域紀錄的那個唯一真正的來源，它從不猜測；而解析器根本不擁有任何紀錄——它只是去抓取、快取，再把授權伺服器告訴它的東西重新供應出去。解析器替你工作；授權伺服器替網域工作。把這兩者分清楚，那麼遞迴對上迭代的分工、快取、甚至安全的那段故事，都會在你腦中保持清晰。