arrow_back回到田野筆記
NETWORKING 已發佈 9 Aug 2026

DNS 解析,從頭到尾

實際走過從輸入網址到收到回應的過程,涵蓋 stub resolver 到權威伺服器。

每次你在瀏覽器中輸入網域,在一個封包到達你想要的網站之前,會啟動一連串的查詢。這個過程的大部分是看不見的,大多數解釋都只說「它就像電話簿」。以下是實際發生的情況,一步步來,包括人們通常會跳過的部分。

stub resolver 並不聰明

你的作業系統本身不執行真正的 DNS 解析。它執行 stub resolver,一小段程式碼,只是把你的查詢轉發給 /etc/resolv.conf(Linux)或網路介面卡設定(Windows)中設定的任何 DNS 伺服器。用以下方式檢查你的設定:

cat /etc/resolv.conf

這個檔案通常指向你的路由器(例如 192.168.1.1)、你的 ISP 的 resolver、或公開的 resolver,如 1.1.1.1 或 8.8.8.8。stub resolver 本身沒有快取邏輯,超過作業系統或像 systemd-resolved 這樣的本地服務提供的範圍之外。

recursive resolver 執行真正的工作

一旦你的查詢到達 recursive resolver,那個伺服器接手尋找答案的工作,即使它必須詢問多個其他伺服器才能得到。如果答案已經從先前的查詢快取,你立即得到它。用以下方式檢查 TTL:

dig example.com

查看 ANSWER SECTION — 記錄類型前面的數字(例如 A 前面的 300)是以秒為單位的 TTL。這是 resolver 在再次詢問之前被允許快取記錄的時間長度。

如果沒有快取,recursive resolver 開始從 DNS 層級的根部走下去。

根伺服器、TLD 伺服器和權威伺服器

有 13 個根伺服器位址(a.root-servers.net 到 m.root-servers.net),每個都被許多實體機器透過 anycast 路由支援。根伺服器不知道 example.com 住在哪裡,但它知道哪些伺服器處理 .com,所以它交回一個參考。

Resolver 接著詢問一個 .com TLD 伺服器,它再次不知道最終答案,但知道哪些 nameserver 對 example.com 具有權威性。你可以自己看到這個委派:

dig +trace example.com

這個命令顯示每個跳點:根伺服器,然後 TLD 伺服器,然後該網域的權威 nameserver,以實際的 A 或 AAAA 記錄作為結尾。這是從視覺上而非理論上理解 DNS 的最佳單一命令。

權威 nameserver 是最後一站。它是網域擁有者實際設定的伺服器,通常透過註冊商的 DNS 面板或 Route 53 或 Cloudflare DNS 這樣的服務。這是整個過程中唯一擁有真實、規範答案而不是快取副本或參考的伺服器。

你實際會遇到的記錄類型

A 記錄將名稱對應到 IPv4 位址,AAAA 對 IPv6 也是一樣。CNAME 指向另一個名稱而不是 IP,這是像 Cloudflare 或 Fastly 這樣的 CDN 在不暴露原始 IP 的情況下路由流量的方式。MX 記錄處理郵件路由,TXT 記錄攜帶任意文字,現在最常用於 SPF、DKIM 和網域驗證字串。NS 記錄告訴世界哪些伺服器對一個區域具有權威性,這是首先使委派成為可能的記錄類型。

快取實際存在的地方

快取同時發生在多個層級:瀏覽器本身(Chrome 有自己的 DNS 快取,在 chrome://net-internals/#dns 可以檢視),OS resolver 快取,本地路由器,以及上游的 recursive resolver。這就是為什麼 DNS 變更在一個裝置上看起來立即生效,在另一個裝置上卻需要數小時才能出現 — 你沒有訪問同樣的快取。

當你在計畫遷移前降低記錄的 TTL,你並沒有立即加速任何東西。你只是縮小了一旦變更實際發生之後過時資料可能持續的時間視窗。至少在一個 TTL 週期前做這件事,而不是在切換前五分鐘。

這對排除故障為何重要

當一個網站無法訪問時,dig +trace 準確地告訴你哪一層有問題:根伺服器/TLD 問題看起來完全不同於配置錯誤的權威伺服器或你自己機器上的過時快取。將 dig example.com 與已知良好的 resolver(如 dig example.com @1.1.1.1)做比較,隔離問題是在你的本地 resolver 還是網域的實際 DNS 設定上。

DNS 從外面看很簡單,因為它通常在 100 毫秒以內解析,沒有人去想它。在內部,它是一個分散式、快取式、階層式的查詢系統,自 1980 年代以來結構上基本未變,這對原始設計有多好是個很好的論證。

如果你想更深入研究,Korra Studio 在 DEFENSE_GRID 上有相關的段落,涵蓋 DNS 安全擴展、DNS 隧道作為資料外洩技術,以及用 Python 從頭建立你自己的 resolver。

本文由 AI 協助撰寫,經 Michal Pilch(CISSP)審核並發佈,Korra Studio。

準備好更進一步了嗎?

這是 Korra Studio 知識庫中的一篇筆記——該平台將每個主題與一對一的師資配對。

免費開始arrow_forward