什麼是 DNS 轉發？運作原理與重要性解析
什麼是 DNS 轉發？瞭解轉發器與遞迴解析器的差異、快取與故障轉移的運作方式，以及轉發在現代網路中的應用。
Published 2026年10月23日
DNS 轉發是指 DNS 解析器將客戶端的查詢傳送到另一個 DNS 伺服器 (即轉發器)，而不是直接透過 DNS 層級結構進行名稱解析的過程。本機解析器仍可從其快取中提供答案並套用本機策略，而上游解析器則會在需要時執行完整的查詢。但如果該上游伺服器故障，到底是 DNS 的哪一個部分出問題？
在設定網路或嘗試解釋網站為何無法載入時，這項差異至關重要。轉發解析器不只是傳遞封包：它可以在本機回應熟悉的請求、將選定的查詢定向至不同的伺服器，並決定由哪個解析器處理使用者的 DNS 流量。
目錄
- DNS 轉發的真實涵義
- 追蹤從用戶端到回應的查詢流程
- 轉發與遞迴及權威服務有何不同
- 條件式轉發、Split Horizon 與迴圈預防
- 快取與 TTL 如何塑造轉發效能
- 在轉發、根提示遞迴與加密 DNS 之間進行選擇
- 在您的網路上實作轉發功能
DNS 轉發的實際意義
可以將本機解析器想像成收發室的前台。用戶端透過名稱請求網站，解析器會檢查自己是否已經知道答案。如果快取中有有效的答案，就會將其返回。如果沒有，它會將查詢傳送到上游 DNS 伺服器（即轉發器），由其處理查詢並返回回應。
這種配置將兩項工作分開。本機解析器面向網路的用戶端，可以套用本機規則。上游解析器則承接本機伺服器無法從其快取或本機資料答覆的名稱解析工作。因此，轉發是一種架構功能，而非自動等同於安全性產品。
DNS 出現於 1983 年 11 月，當時 RFC 882 和 RFC 883 引入了階層式命名系統，以取代日益難以管理的 HOSTS.TXT 模型。在 DNS 出現之前，管理者仰賴人工維護的名稱對應位址對照表。正如 DNS 歷史時間表 所記載，1987 年 11 月的 RFC 1034 和 RFC 1035 取代了原始規範，成為現代 DNS 架構的基石標準。
您會在何處遇到轉發
家用路由器、企業網路、公共 WiFi、學校與雲端環境皆可使用轉發功能。組織可以使用它將一般網際網路尋找傳送至受控遞迴服務，同時保留對快取、記錄檔記錄、內部名稱或攔截規則的本機控制權。
實用的心智模型非常簡單：本機解析器是受控的前台；上游解析器則是執行完整查詢的專家。這個模型也讓定位問題變得更容易。即使上游解析器不可用或返回錯誤，用戶端仍可能成功連線到前台。
追蹤從用戶端到解答的查詢過程
典型的尋找始於裝置向其本機解析器查詢名稱。解析器會先檢查其快取。如果儲存的答案仍然有效，它可以直接回傳答案，無須聯絡上游伺服器。如果沒有可用的快取答案，解析器就會將查詢轉發至上游遞迴解析器。
在 DNS 術語中，轉發涉及解析器發送設定了需要遞迴 (RD) 位元的查詢。該位元表示要求接收端的解析器解析該查詢，而非僅僅在沒有該請求的情況下轉發封包。RFC 7719 的詞彙定義 將轉發與盲目封包轉發區分開來。
當快取未命中時，上游遞迴解析器會執行查詢工作。它可能會使用自己的快取，或者透過 DNS 層級結構查詢答案。隨後，回應會透過轉發解析器傳回給用戶端。
兩種可能的路徑
- 快取命中：本機解析器回傳有效的快取答案。上游伺服器不會參與該次尋找。
- 快取未命中：本機解析器將查詢傳送至上游，接收回應並將其回傳給用戶端。
這種分工也界定了實用的責任分工。本機解析器可以套用特定於網路的控制措施、保留記錄檔、使用 split-DNS 規則，或強制執行 DNSSEC 驗證策略。當本機解析器無法從其快取或本機資料提供答案時，上游解析器就會執行遞迴尋找。
疑難排解提示：若本機解析器可回應用戶端，但當其快取不包含解答時查詢失敗，請在假設授權 DNS 服務發生故障之前，先檢查轉發路徑與上游回應。
轉發與遞迴及授權服務有何不同
DNS 轉發、遞迴、代理與權威服務代表不同的角色。單一系統可以承擔多個角色，但這些術語不能互換。在典型的轉發設定中，本機伺服器服務用戶端並維護快取或原則；上游遞迴解析器則為快取未命中執行解析。
| 角色 | 發起者 | 執行完整尋找 | 保存權威資料 | 典型失敗症狀 |
|---|---|---|---|---|
| 轉發器 (Forwarder) | 本地解析器向其發送查詢 | 通常在充當上游遞迴解析器時執行 | 不一定 | 來自上游服務的逾時或錯誤 |
| 遞迴解析器 (Recursive resolver) | 用戶端或其他解析器請求解析 | 是，透過使用快取或穿過 DNS 階層架構進行查詢 | 不一定 | 解析錯誤、逾時或尋找失敗 |
| 代理伺服器 (Proxy) | 用戶端或服務向其發送流量 | 固有本質上否；代理會根據其設計轉發請求 | 否 | 代理請求失敗或無法到達目的地 |
| 權威伺服器 (Authoritative server) | 解析器針對其服務的網域進行查詢 | 否，它為其區域 (Zone) 提供資料 | 是，針對其服務的區域 (Zone) | _
表中的關鍵區別在於由誰執行完整的查詢。轉發解析器會將未答覆的查詢繼續傳送；遞迴解析器則透過查詢權威伺服器來處理解析。權威伺服器為其管理的網域提供記錄，而不是代表用戶端搜尋階層架構。
為何這項差異會改變疑難排解方式
即使授權 DNS 基礎設施正常運作，轉發解析器仍可能傳回上游超時、SERVFAIL 或不再適用的快取答案。在這種情況下，若僅對授權伺服器進行疑難排解，可能會讓您走偏方向。請檢查是哪一個解析器收到請求、該解析器是否有快取答案，以及在下一個跳躍點發生的情況。
此外還有信任依賴性的問題。RFC 7719 探討了解析器術語，包括轉發器 (Forwarder) 與遞迴解析器之間的區別。關於快取毒化攻擊的研究區分了這些角色，因為轉發器依賴其使用的上游解析器的完整性。如果內容控制是設計的一部分，網路也可以使用 DNS 過濾，在裝置連線至目的地之前對查詢套用策略。
條件轉發、Split Horizon 與迴圈預防
轉發不一定要將每個未答覆的查詢傳送到同一個上游伺服器。透過條件式轉發，解析器會將指定網域的查詢傳送到指定的伺服器。例如，網路可以將內部名稱的請求導向至內部 DNS 服務，並將其他請求傳送到受管理的遞迴解析器。
一個相關的概念是 雙向 DNS (split-horizon DNS)。它允許網路根據請求來源，針對相同的名稱傳回不同的答案。組織內部的人員可能會收到內部答案，而外部請求者則會收到不同的答案。本機解析器成為將內部名稱保持在適當路徑上的決策點。
設定必須明確指出哪個解析器擁有每個查詢路徑。將內部名稱傳送到錯誤上游伺服器的規則，可能會產生外部解答、解析失敗，或導致網路不同部分之間的結果不一致。
預防解析器迴圈
當一個解析器將查詢傳送至第二個解析器，而該解析器最終又將查詢傳回時，就會發生轉發迴圈。查詢會在伺服器之間循環，導致重複請求、逾時以及資源耗盡。修復方法是規劃轉發路徑，並確保沒有解析器鏈指向較早的伺服器。
某些名稱也需要明確的邊界。RFC 9539 指出例如 home.arpa 等命名空間絕不能轉發超出其預期的本地範圍。原本運作正常但在新增第二個轉發器後出問題的解析器，可能是產生了迴圈；而原本在本地解析的名稱若開始向外公開解析，則可能需要更具體的轉發或本地分區規則。
下方影片提供了 DNS 轉發概念的另一個視覺化介紹。
快取與 TTL 如何塑造轉發效能
轉發器的快取運作方式就像有幫助的中介者記憶：一旦它從上游獲取了答案，就能自行回答下一個相同的問題。這單一行為解釋了轉發對效能產生的絕大部分影響。每一次快取命中都可以消除一次往返上游解析器的時間。每一次未命中，則會在實際查詢開始之前額外增加一次往返。
每個記錄的 生存時間 (TTL) 設定了該記憶的邊界。授權伺服器會發布 TTL，且路徑上的任何解析器僅能在其保持有效期間重複使用快取的答案。短 TTL 可以保持答案最新，但會傳送更多查詢到上游。長 TTL 可以減少上游流量，但在基礎設施變更後，可能會讓客戶端取得過期的位址。
快取也會沿著路徑堆疊。查詢可以由客戶端的快取、轉發器的快取或上游解析器的快取來提供服務，而且每一層都會執行自己的 TTL 倒數。當使用者回報答案過期時，修復方式取決於哪一層保存了該答案，因此在疑難排解期間，請將每個快取視為獨立的疑點，而不是直接清除最近的快取。
測量不應僅限於平均延遲
平均尋找時間可能會掩蓋影響部分使用者或部分查詢的問題。請追蹤快取命中率、中位數與尾端尋找延遲、上游逾時率以及負向快取行為。這些指標有助於區分是上游服務速度緩慢，還是轉發器一直錯失快取機會或對失敗尋找處理不當。
DNSSEC 帶來了另一個複雜情況。驗證解析器除了答案本身之外，還會擷取簽章與金鑰，因此針對已簽署名稱的快取未命中，成本高於未簽署名稱。已快取的驗證答案可以跳過該重複工作，這使得命中率在驗證路徑上顯得更加重要。
沒有單一數字可以預測特定網路上的查詢時間。結果取決於每一層的快取狀態、上游回應能力、驗證工作、傳輸設定，以及轉發器無回應後的重試機制。運作良好的轉發器也會原封不動地傳遞回應碼、截斷行為、DNSSEC 記錄和標記，因此客戶端會看到授權端所傳送的答案。
在轉發、Root-Hints 遞迴與加密 DNS 之間進行選擇
轉發與根提示權威遞迴（root-hints recursion）各具不同的權衡。使用轉發時，企業組織會選擇上游解析器來處理未解答的查詢。這能簡化本地營運並集中管理政策，但會使網路依賴所選的上游服務。採用根提示權威遞迴時，解析器會自行執行疊代尋找，這減少了對單一上游遞迴服務的依賴，但也讓該解析器承擔更多解析責任。
| 架構選擇 | 解析發生的位置 | 主要營運權衡 |
|---|---|---|
| 轉發 (Forwarding) | 所選的上游遞迴解析器處 | 集中式管理，但具備上游依賴性 |
| 根提示遞迴 (Root-hints recursion) | 本地遞迴解析器處，透過層級結構進行查詢 | 擁有更多本地控制權，但也需要承擔更多直接解析的責任 |
| 用戶端導向的加密 DNS | 用戶端透過加密連線存取的解析器處 | 本地網路可能無法檢視或控制網域查詢 |
加密 DNS 讓選擇變得更加複雜。DNS over TLS 與 DNS over QUIC 可以保護傳輸中的 DNS 流量，但關鍵在於加密在哪裡終止。如果用戶端直接將查詢加密傳送至外部解析器，本地轉發器可能無法看到可用的網域查詢。如果加密終止於經過批准的企業解析器，該解析器仍可套用網路政策並將查詢轉發至上游。
公共 WiFi 需要周全的原則
公共 WiFi 營運商也必須考量 Captive Portal。在使用者登入之前，裝置可能需要進行驗證前的名稱解析與連線檢查。加密的 DNS 可能會使 Portal 偵測變得複雜或延遲，因此營運商需要決定哪些解析器是經過核准的、備援機制應如何運作，以及是否需要任何例外狀況。
保護性 DNS 服務可以部署在所選的解析路徑中，並在連線建立前評估查詢。Purple Shield 是專為場域與訪客 WiFi 網路所設計，具備依類別分類的內容過濾、DNS 層級的威脅阻擋，以及可依網路管理的策略。它可以作為獨立服務部署，也可以與 Purple Access 網路整合。對於正在權衡 DNS 控制與更廣泛的 Web 流量控制的團隊，安全 Web 閘道概述 說明了不同層級的執行方式。
將轉發應用於您的網路
轉發會將部分 DNS 工作負載集中在組織所選擇的上游服務中。使用 DNS-OARC 的 Day in the Life 資料集進行測量發現，大約有 99% 的遞迴解析器會產生中等的查詢量，而約有 1% 的行為較為積極。該較小的群組占了 2018 年觀察到的 DNS 流量的 98% 以及 2019 年的 93%；研究人員估計，該群組在 2018 年包含約 8,300 個解析器，在 2019 年則超過 14,000 個（積極解析器行為研究）。本地解析器可以將請求傳送到會快取並重複使用答案的上游遞迴服務，但這會提高對其可用性與行為的依賴度。
在部署或變更轉發之前，請確認：
- 上游伺服器相互獨立：在設計允許的情況下，請至少設定兩個轉發器。
- 故障具備明確的因應機制：設定逾時與重試行為，並瞭解當上游沒有回應時用戶端會收到什麼內容。
- 監控涵蓋異常徵兆：密切注意 SERVFAIL 回應、逾時以及回應延遲。
- 隱私期望明確：明確決定哪家上游解析器可以檢視轉發的查詢。
如果 DNS 過濾是您訪客網路原則的一部分，請將其與您更廣泛的 WiFi 內容過濾做法 進行比較。然後稽核您的網路轉發至哪一個解析器，並確認其原則、可用性與隱私姿態符合您的預期。
Purple Shield 會在裝置連線前檢查 DNS 尋找，並為場地與訪客 WiFi 網路提供內容過濾和威脅攔截功能。如果您正在評估轉發功能如何支援這些控制措施，請造訪 Purple Shield 以探索其部署選項。