總覽與定位
DNS 把人類可讀的網域名稱轉成機器可連的 IP——是幾乎所有網路請求的第一跳。
你輸入 api.example.com 時，作業系統與瀏覽器並不知道該連哪個 IP。
DNS（Domain Name System） 是分散式的命名系統：把名稱解析成 A／AAAA 等紀錄，
再交給 TCP／UDP 真正建連。沒有 DNS，幾乎所有現代服務都動不了。
DNS 通常跑在 UDP／TCP 53，介於「應用要連誰」與「L3 路由怎麼走」之間。
本篇接續 IP／LAN／NAT：有了位址與路徑之後，還缺「名稱 → 位址」這層目錄服務。
解析流程：遞迴與迭代
同一個「查 IP」請求，在 Stub 與 Resolver 眼裡是兩種完全不同的協議行為。
實務上幾乎所有客戶端都走遞迴查詢（Recursive Query）：Stub 對 Resolver 設 RD（Recursion Desired）旗標， 期望對方「給我最終答案」。Resolver 對外則多半用迭代查詢（Iterative Query）：自己一步步問 Root、TLD、Authority， 每次只拿到「下一步去哪問」的 referral，直到拿到最終紀錄。
- 客戶端只發一問，等最終答案（或錯誤）
- 快取命中時幾乎零延遲
- 客戶端不必知道 Root／TLD 拓樸
- 每次回應可能是 referral（NS＋glue）
- Resolver 自己決定下一跳
- 可並行／快取各層 NS，降低 Root 壓力
sequenceDiagram
participant C as Client
participant R as Resolver
participant Ro as Root
participant T as TLD
participant A as 權威
C->>R: 遞迴查詢 RD=1
R->>Ro: 迭代查詢
Ro-->>R: .com NS referral
R->>T: 迭代查詢
T-->>R: example.com NS
R->>A: 迭代查詢
A-->>R: A 紀錄
R-->>C: A 紀錄
看 Resolver 那條生命線：它上面有三組往返，客戶端卻只有一組——「誰在做迭代、誰只發一次遞迴」的分工全寫在這個不對稱裡。三個 referral（虛線）都不是最終答案，只是「下一步去哪問」。
想在真機看這條迭代鏈路，用 dig +trace——它會自己扮演 Resolver，從 Root 開始一層層問下去，把每個 referral 印出來：
$ dig +trace www.example.com
. NS a.root-servers.net. ... # 1) 從 Root hints 起步，拿到根區 NS
com. NS a.gtld-servers.net. ... # 2) 問 Root → 得到 .com 的 NS（referral）
example.com. NS ns.example.com. # 3) 問 .com TLD → 得到 example.com 委派
www.example.com. A 93.184.216.34 # 4) 問權威 → 拿到最終 A 紀錄對照左邊：每個 NS 行都是一次 referral（「下一步去哪問」），只有最後一行才是最終答案。少了 +trace 的普通 dig www.example.com，則是直接打你系統設定的 Resolver、由它代跑整條鏈——多半直接命中快取。
遞迴／迭代是查詢行為與誰負責走完整條鏈的差異，不是兩種不相容的 DNS 協議。 面試若只背「遞迴比較快」而不提「誰在做迭代、誰在快取」，容易被追問穿幫。
伺服器階層：Root、TLD、Authority
DNS 是樹狀委派：每一層只負責「這一截名稱」與「下一層 NS 在哪」。
以查 www.example.com 的冷快取路徑為例：
- Root（.）：不存業務紀錄；回傳
.com的 NS 與 glue A／AAAA。 - TLD（.com）：回傳
example.com的權威 NS（常來自註冊商／DNS 託管商）。 - Authoritative：回傳
www.example.com的最終答案（例如 A →93.184.216.34）。
Authority 管理的單位叫 Zone。Zone 檔裡的 NS 紀錄宣告「誰是這區的權威」；
父 Zone（如 .com）必須有對應的委派，否則全世界找不到你的伺服器——這也是「剛買網域卻解析不到」的常見根因。
委派 example.com 給 ns1.example.com 時會遇到雞生蛋問題：TLD 只回「權威 NS 叫 ns1.example.com」，但你要先解析 ns1.example.com 才知道它的 IP，而它本身又在 example.com 這個 Zone 內——要問它得先找到它，形成死循環。解法是 TLD 在回覆 NS 委派時，順帶附上該 NS 的 A／AAAA 位址，這筆「額外附帶的黏合紀錄」就是 glue record，讓 Resolver 不必再繞回來查就能直接連上權威。只有當 NS 名稱落在被委派的 Zone 之內（in-bailiwick）時才需要 glue；若 NS 用的是外部網域（如 ns.some-dns-provider.net）則不需要。
| 層級 | 回答什麼 | 典型運營者 | 開發者何時碰到 |
|---|---|---|---|
| Root | TLD 的 NS | Root Server Operators | 幾乎從不直接設定；Resolver 內建 Root hints |
| TLD | 網域 NS 委派 | Verisign、各 ccTLD | 改註冊商 Nameserver 時 |
| Authoritative | Zone 內最終紀錄 | Cloudflare、Route53、自建 Bind | 加 A／CNAME／MX、切藍綠、驗證所有權 |
階層委派：每一層只導航，最終真相在 Authoritative Zone。
常見記錄類型
面試與上線最常考的五種：A、AAAA、CNAME、MX、NS——各管一件事，不要混用。
| 類型 | 語意 | 典型用途 | 注意 |
|---|---|---|---|
A |
名稱 → IPv4 | 網站／API 主機 | 可多值做簡易 DNS LB |
AAAA |
名稱 → IPv6 | 雙棧服務 | 客戶端 Happy Eyeballs 會並行試 |
CNAME |
名稱 → 另一名稱 | CDN／別名／驗證 | 不可與同名其他紀錄並存；apex 常受限 |
MX |
郵件交換主機 | 收信路由 | 帶 priority；值應是主機名非 IP |
NS |
Zone 權威伺服器 | 委派與託管 | 父子 Zone 必須一致，否則裂腦 |
紀錄類型對照：選錯類型比設錯 IP 更難除錯。
CNAME 指向另一個名稱，Resolver 會繼續追到 A／AAAA。
根網域（apex，如 example.com）常因需同時存在 NS／MX 而不能放 CNAME——這才有 ALIAS／ANAME 等廠商擴充。
面試提到 CDN 時，能講清「為何 www 用 CNAME、apex 用 A／ALIAS」會加分。
TTL 與各層快取
開發者最常誤解的地方：改了 DNS 卻「立刻／永遠」不生效——多半是快取層次沒對齊。
TTL（Time To Live） 是權威伺服器在答案上附的「允許快取多久（秒）」。 它不是「保證在 TTL 秒內全球同步切換」，而是「快取端最長可保留多久」的上限建議。
正向答案的快取時間由該筆紀錄自己的 TTL 決定；但「查無此名（NXDOMAIN）」這種負向答案沒有具體紀錄可附 TTL，於是改由該 Zone 的 SOA（Start of Authority）紀錄裡的 minimum 欄位（RFC 2308）決定要快取多久。每個 Zone 有且只有一筆 SOA，記錄該區的主要 NS、負責人信箱、序號（serial，控制 secondary 同步）與各項計時器。所以「拼錯網域會卡一陣子」正是負向快取按 SOA minimum 在生效。
nscd、systemd-resolved 都會插手。1.「把 TTL 改成 60 就 60 秒內全球切完」——舊 TTL 仍被舊快取遵守，要提前降 TTL 再切。
2.「flush DNS 就能逼所有人更新」——你只能清本機；別人的 ISP Resolver 不受影響。
3.「NXDOMAIN 不會被快取」——負向答案也有 TTL（SOA minimum 等），拼錯網域一樣會卡一陣子。
| 場景 | 建議 TTL 心智 | 理由 |
|---|---|---|
| 穩定官網 A 紀錄 | 較長（如 1h–24h） | 降低查詢量與延遲 |
| 即將切換／災備演練 | 提前降到數分鐘 | 縮短舊答案殘留窗口 |
| 動態服務發現（少用公網 DNS） | 極短或不走公網 DNS | DNS 不是強一致註冊中心 |
TTL 是快取契約，不是全球原子開關。
互動 · TTL 決定這一次要問幾層
調 TTL、推時間，再按「下一問」——每一步要問誰，全由各層快取的剩餘 TTL 算出來。
左尺「還剩多少時間」：五列共用同一條時間橫軸（平方根壓縮，才能同時容納 30 s 與 48 h），藍色細線是你拖到的「時間流逝」位置。線掃過哪一列，那一列就熄滅。Root hints 是設定檔不是快取，永遠不過期，所以畫成常駐斜紋；「即將過期」是殘量低於該層 TTL 10% 的呈現用分箱，不是協定規則。
右尺「花了多少毫秒」：實線格是這次真的發生的問答（寬度正比於該段 RTT），虛線格是被快取省掉的層與它省下的毫秒。一次問答算一個 hop，最後把答案回覆 Stub 不另計 RTT。
面試折衷與實務選型
DNS 看起來「只是查 IP」，但選型牽涉延遲、切換速度、可用性與安全。
| 議題 | 常見選項 | Trade-off |
|---|---|---|
| TTL 長短 | 長 TTL vs 短 TTL | 長：省查詢、穩；短：切換快、權威壓力大 |
| DNS 負載均衡 | 多 A 紀錄 vs GSLB | 多 A 簡單但不懂健康檢查；GSLB 聰明但複雜、仍受 TTL 綁架 |
| 權威託管 | 雲 DNS vs 自建 | 雲：Anycast／任播／API；自建：可控但要扛 DDoS 與可用性 |
| 安全 | DNSSEC / DoH / DoT | 防污染與竊聽；代價是複雜度、延遲與除錯成本 |
DNS 選型沒有銀彈：切換速度與快取效益永遠在拉扯。
原生 DNS 有兩個安全弱點：答案可被竄改（快取污染／中間人偽造 referral），且查詢明文可被竊聽。三個常混為一談、其實正交的機制各解一半：
| 機制 | 保護什麼 | 怎麼做 | 代價 / 注意 |
|---|---|---|---|
| DNSSEC | 真實性 / 完整性 | 權威用私鑰對紀錄簽章（RRSIG），沿信任鏈（DS/DNSKEY）逐層驗證 | 不加密（內容仍明文可見）；金鑰輪替、簽章過期是常見營運事故 |
| DoT（DNS over TLS） | 傳輸機密性 | 把 stub↔resolver 查詢包在 TLS，走專用 port 853 |
獨立 port 易被網管識別/封鎖；不保證答案未被權威端偽造 |
| DoH（DNS over HTTPS） | 傳輸機密性 | 查詢包進 HTTPS（port 443），混在一般網頁流量中 |
難被封鎖但也繞過企業 DNS 監控；同樣不驗證答案真偽 |
關鍵區分：DNSSEC 管「答案是不是被竄改」，DoT／DoH 管「查詢過程有沒有被偷看」——兩者正交，完整防護會同時用。
Q：為什麼改了 A 紀錄還連到舊 IP？
答：列三層快取＋舊 TTL 仍有效；解法是提前降 TTL、等窗口、必要時雙寫一段時間。
Q：CNAME 和 A 差在哪？
答：A 直接給 IP；CNAME 給別名需再解析；apex 常不能 CNAME。
Q：DNS LB 能取代健康檢查 LB 嗎？
答：不能——TTL 與客戶端快取會讓故障摘除變慢且不均勻。