什麼是 DNS 查詢，以及為什麼網路需要使用它

DNS 查詢是解析器尋找與人類可讀域名相關聯之資訊（最常見的是 IP 位址）的過程。經典的處理流程會先檢查本機資訊、找出最佳伺服器、向其查詢答案，最後傳回並快取結果。

您可能正在飯店、學校或醫院的 WiFi 上點擊熟悉的網站閱讀此內容。您的裝置已連線，但在頁面載入之前，網路需要找出該網站的所在位置。請將 DNS 視為協助您裝置尋找服務的分散式目錄，而不僅僅是網站的電話簿。

這種差異在共享 WiFi 上至關重要。處理查詢的解析器會影響頁面開啟的速度、網域是否被封鎖，以及場地的網路是否能查看或管理該查詢。加密、真實性、策略執行與匿名性是不同的特性，混淆這些特性可能會導致不良的安全決策。

目錄

• DNS 查詢的實際運作方式
  • 這是目錄查詢，而非頁面請求
• DNS 查詢內部的各個階段
  • 快取命中或快取未命中
  • TTL 保持快取答案的即時性
• 讓查詢具備擴充性的階層架構
  • 根系統如何發展
• 為什麼 DNS 查詢是執行策略的據點
  • DNS 策略能涵蓋與不能涵蓋的範圍
• 加密 DNS 真正改變了什麼
  • 共享 WiFi 中的權衡取捨
• 當 DNS 查詢在共享 WiFi 上失敗時
  • 在變更設定之前先區分症狀
• 下一步如何選擇保護性 DNS
  • 比較策略與營運適配度

DNS 查詢實際上的運作方式

訪客點擊飯店 WiFi 網路上的連結。瀏覽器知道網域名稱，但網路裝置是使用 IP 位址來路由流量。DNS 查詢是解析器尋找與該易讀名稱相關聯之資訊（最常見的是 IP 位址）的過程，以便裝置可以開始連線至該服務。

電話簿是一個有用的初步類比，但 DNS 更像是一個分散式的即時目錄。不同類型的記錄支援郵件傳遞、別名、服務探索、反向查詢以及其他網路功能。DNS 不僅僅是將網站名稱對應到位址，它還能協助應用程式尋找一系列的網路服務。

基礎 DNS 規範出現於 1987 年 11 月，當時網際網路工程任務組出版了 RFC 1034。該文件描述了一個四階段演算法：檢查本機資訊、找出最佳伺服器、向其查詢直到收到回應，並在適當時機返回與快取結果（RFC 1034）。快取非常重要，因為解析器可能已經擁有來自先前請求的可解答。

是目錄查詢，而非網頁請求

當您的裝置要求查詢名稱時，它並不是要求 DNS 傳送網頁，而是要求提供有助於應用程式連線至相關服務的資訊。隨後瀏覽器會將該答案作為其連線流程的一部分。

在訪客 WiFi 上，這使查詢成為一個有用的共享決策點。解析器會在傳回位址之前先看到請求的名稱，因此網路營運商可以利用該時刻來套用策略。如需瞭解 DNS 問題如何影響可用性的實用概述，請參閱這篇 預防 DNS 故障導致停機 指南。

瞭解這個流程有助於您追蹤查詢的去向、明白為何快取解答速度更快，並認識 DNS 在共用 WiFi 上能控制與不能控制的事物。速度、策略、加密與查詢失敗彼此相關，但它們並不是同一個問題。

DNS 查詢內部的各個階段

飯店房客在瀏覽器中輸入 example.com 並按下 Enter。頁面尚未載入。在載入之前，域名會通過固定的查詢序列，而在共用 WiFi 上，每個步驟都給予場地網路一個全新的機會來觀察或引導該要求。

裝置的虛擬解析程式（stub resolver）透過將遞迴查詢傳送到快取解析程式（caching resolver）來開啟序列。場地、網路服務提供者或獨立的 DNS 服務都可能營運該解析程式，而選擇何者非常重要，因為這決定了誰能最先看到該查詢。

快取命中或快取未命中

快取解析器會先檢查其記憶體。仍然有效的記錄會直接返回，這種快取命中（cache hit）可跳過所有的上游通訊。遺失或過期的記錄則是快取未命中（cache miss），解析器接著會透過 DNS 層級進行查詢：根伺服器將其引導至正確的頂級網域，TLD 伺服器將其引導至該網域的授權域名伺服器，最後由該域名伺服器返回記錄。

對於網站而言，答案通常是包含 IPv4 位址的 A 記錄，或是包含 IPv6 位址的 AAAA 記錄。其他記錄類型則涵蓋郵件路由與別名等工作。

這些階段也引發了不同的問題。加密決定了誰可以在傳輸過程中讀取查詢。真實性決定了答案是否來自網域的營運者。策略決定了解析器是否回傳答案。匿名性則決定了哪些方從一開始就獲知了該名稱。

TTL 保持快取答案為最新狀態

每個記錄集都包含一個生存時間 (TTL)，即解析器可保留該記錄的最長時間。解析器必須在過期時捨棄該記錄，讓更新後的位址與策略能夠重新循環運作。

一位房客的快取未命中，能為後方的訪客預熱快取。較短的 TTL 可讓變更更快生效；較長的 TTL 則可減少重複的上游查詢。區域營運商在這種權衡中選擇一個平衡點，而共用網路上的每個人都會繼承這個結果。

有些網路會在此順序中插入轉發步驟，將查詢傳送到另一個解析器，而不是直接巡訪架構層級。這篇關於 DNS 轉發如何改變該路徑 的介紹說明了轉折發生的位置。

讓查詢得以規模化擴展的層級架構

DNS 架構層級劃分了職責。最頂層是根伺服器身份，負責引導解析器找到正確的頂級網域。TLD 伺服器負責處理如 .com 和 .org 等網域，而每個網域的授權伺服器則提供該網域內名稱的記錄。

常見的 13 台根伺服器 印象可能會讓人產生誤解。歷史上定義的識別碼共有 13 個（標籤為 A 至 M），由 12 個獨立組織 運營。它們並不只是 13 台實體電腦。Anycast 路由技術讓相同的識別碼得以從全球 900 多個分散的實例提供服務，有助於查詢請求到達鄰近的實例並支援復原能力（ICANN 對根伺服器的概覽）。

根系統如何發展

根系統隨著網路需求的改變而擴展。第一台根伺服器於 1984 年 在南加州大學資訊科學研究所成立。該系統在 1985 年 擴增至 4 台伺服器，1987 年 達到 7 台，1993 年 達到 9 台，並於 1997 年 達到 13 台。如今，根系統同時使用 IPv4 和 IPv6。一項技術概覽指出，除了分散式的 Anycast 實例之外，還有 26 個主要的位址端點，兩種協定各佔 13 個。

這些數字代表架構中的不同部分。這 13 個身份是可識別的根伺服器名稱；位址端點支援 IPv4 與 IPv6；分散式執行個體則有助於從全球各地提供服務。失去對單一執行個體的存取權，並不等於在所有地方都失去了根身份。

這種設計正是為什麼即使查詢依賴全球多層級系統，感覺依然像是在本機進行。解析器可能會聯繫附近的實例，而層級架構則繼續將責任分發給根域名、頂級域名 (TLD) 以及權威營運商。

為什麼 DNS 查詢會是政策執行點

飯店 WiFi 上的筆記型電腦必須先向網路的解析器查詢網域，然後才能連線至任何目標。該請求會通過場地控制的設備，這使得該查詢成為裝置自行連線前的最後一個共同決策點。保護性 DNS 服務可以正常回應、拒絕查詢，或是返回一個無法連線的回應。如果沒有返回可用的地址，連線通常根本不會開始。

正是這個位置賦予了 DNS 原則在訪客網路上的影響力。訪客的手機和筆記型電腦很少安裝管理軟體，因此場地無法在裝置本身安裝控制措施。解析器是每個裝置都會經過的唯一檢查點。在此套用的原則可以封鎖與釣魚、惡意軟體或中控（command-and-control）流量相關的網域，強制執行成人內容或賭博等類別，並套用安全搜尋設定。

時機點加強了這項優勢。強制執行發生在請求階段，也就是應用程式透過該解析器取得位址之前。若要了解在網路其他層級運作的防護措施，請參閱本指南以 保護您的 Microsoft 365 企業網路。

DNS 策略能涵蓋與不能涵蓋的範圍

DNS 強制執行可管理名稱解析，但連線可以繞過它。應用程式可能會重用快取的位址、直接存取 IP、存取從未使用過 DNS 名稱的服務，或是透過場地未指派的加密解析程式傳送查詢。

因此，營運商在評估過濾機制時，會將加密 DNS 行為、應用程式快取以及直接 IP 流量一併納入考量。DNS 過濾在更廣泛的控制措施中發揮著單一層級的作用。這篇關於 DNS 過濾以及策略如何套用於查詢 的指南，詳細介紹了過濾所扮演的角色。

策略也只是信任的其中一個維度。域名是否被允許、回應是否真實，以及是否有人可以在傳輸過程中讀取查詢，這些都是獨立的問題，由不同的機制來解答。

否定答覆同樣值得關注。解析器可以快取 NXDOMAIN 回應（表示請求的網域不存在），而不是再次向上游伺服器詢問相同的缺失名稱。RFC 8020 描述了 NXDOMAIN 斷層 (NXDOMAIN cut)，其中經過驗證的否定答覆也會確立該缺失網域底下的名稱同樣不存在（RFC 8020）。較新的 IETF 指南更要求快取解析失敗結果，以減少無謂的重複查詢。

加密 DNS 真正改變的事物

訪客連上飯店的 WiFi 並存取網站。DNS 查詢是連線前最後的共享決策點之一：裝置會向解析器詢問要使用哪個位址，而解析器可能會套用場地規則。加密該請求僅會改變傳輸途中誰能讀取內容。加密本身並不會改變解析器能看到的內容，也不會讓訪客變得匿名。

裝置會將查詢傳送至遞迴解析器，解析器會查詢答案並將其返回。DNS over HTTPS (DoH) 會加密裝置與該解析器之間的連線。監控 WiFi 的人可能較難讀取或修改查詢，但解析器仍然會收到要求的網域。

DNSSEC 解決的是另一個問題：它讓驗證解析器能夠檢查已簽署 DNS 資料的真實性與完整性。它不會加密查詢。加密、真實性、原則強制執行和匿名性是不同的特性。

共用 WiFi 上的權衡取捨

使用 DoH 的瀏覽器可能會將查詢傳送至由瀏覽器或使用者選擇的解析器，而非由飯店、學校、醫療照護機構或公共 WiFi 營運商指派的解析器。這可能會限制場地所能看到的內容以及其可套用的 DNS 規則。如果場地網路依賴自身的解析器，這也會讓疑難排解變得更加困難。

實際的差別很明顯：DoH 旨在保護查詢傳輸至解析器的路徑；它並不會向該解析器隱藏查詢內容。DNSSEC 則有助於驗證已簽署的答案。場所唯有在相關查詢通過其控制或已整合的解析器時，才能執行 DNS 策略，且這兩項技術都無法讓使用者完全匿名。

當 DNS 查詢在共用 WiFi 上失敗時

兩位訪客連線到同一個飯店 WiFi。一位開啟了熟悉的網站；另一位卻看到錯誤訊息，即使兩台裝置都顯示已連線。差異可能在於查詢路徑、裝置快取，或是每個用戶端所使用的解析器。

解析器可能會無法存取、傳回不完整的解答，或是無法解析僅存在於組織內部網路的名稱。網路也可能會封鎖透過 UDP 或 TCP 通訊埠 53 傳送的傳統 DNS 流量，或者因為策略封鎖了所要求的網域而故意傳回失敗。

在變更設定前先排查症狀

設想一個學校的內部入口網站，該網站可透過學校指定的解析器正常運作，但無法透過外部公開解析器運作。學校可能會使用雙向 Split-horizon DNS，其中內部名稱僅能透過該網路的解析器存取。變更裝置的 DNS 設定可能會讓公開網站順利載入，卻會破壞對內部入口網站的存取。

加密 DNS 可能會增加另一個故障點。一項 2025 年的研究指出，HTTPS DNS 查詢佔觀察到的 DNS 流量約 8%，且不完整的回應增加了查詢量（加密 DNS 流量研究）。如前所述，另一項針對解析器的研究發現，三分之一公開宣傳的加密解析器無法回應。因此，用戶端可能使用的是無法如期回應的加密解析器，即使場地指派的解析器正常可用。

疑難排解規則：在要求房客變更 DNS 設定之前，請先確認用戶端實際使用的是哪一個解析程式。

對於營運者而言，請先釐清可能的原因，而不是將每個查詢錯誤都以相同方式處理：

• Captive Portal： 裝置尚未完成 WiFi 登入或條款頁面確認。
• 快取過期： 用戶端或解析器保存了過期的答案。
• 上游服務中斷： 設定的解析器無法完成請求。
• Port 53 被阻擋： 傳統 DNS 流量被阻擋或無法連線至解析器。
• 不支援 DoH 或 DoT： 用戶端的加密 DNS 行為未被網路支援或管理。
• 策略阻擋： 解析器刻意不提供答案。

DNS 錯誤也可能代表 WiFi 安全問題，而非解析程式問題。如需識別欺詐性無線存取點的指引，請參閱 RDE Technologies 的邪惡雙胞胎預防指南。

接下來如何選擇保護性 DNS

連接您 WiFi 的每台訪客裝置在連線前，仍然必須先向某些物件詢問方向。網路營運商真正的選擇在於由誰來回答這個問題：裝置剛好帶有的解析器、老舊防火牆的規則集，或是由您控制的防護性 DNS 服務。每個選項都會改變您在這個最後共享決策點上能夠執行的策略強度以及保留的證據數量。

做法	非託管裝置	決策點	營運者佐證
用戶端選定的解析器	通常不在場地的 DNS 策略範圍內	由裝置或瀏覽器選擇的解析器	有限的全網可視性
僅靠老舊防火牆	涵蓋範圍取決於防火牆規則與流量路徑	該網路可用的防火牆控制項	防火牆記錄與警報
雲端保護性 DNS 解析器	可涵蓋使用網路指定解析器的裝置	傳回位址前的網域查詢	來自解析器的查詢與阻擋報告

對於飯店旅宿、教育、醫療照護、公共部門以及多據點網路，如前所述，Purple Shield 是一個防護型的 DNS 選擇。它會在連線開始前評估解析請求、套用成人與賭博等內容分類、強制在 Google、Bing 及 YouTube 上執行安全搜尋，並封鎖命令與控制 (C2)、網路釣魚和惡意軟體網域。該廠商還介紹了旨在比標準黑名單更早標記新興威脅的 AI 輔助訊號，以及在 DNS 層級進行廣告與追蹤器封鎖，據稱可減少網頁容量和流量。

比較策略與營運契合度

該服務支援按 SSID、VLAN、場地和時程套用原則，並提供儀表板、品牌客製化封鎖頁面以及失敗關閉（fail-closed）運作模式。其服務說明指出不需要用戶端代理程式或變更防火牆，引用了公開的正常運行時間 SLA，並列出符合 Friendly WiFi 和 Internet Watch Foundation 標準。請將這些視為廠商的主張，並根據您自己的報表與韌需求進行評估。

DNS 過濾也只能回答資安問題的一部分。加密可對路徑上的觀察者隱藏查詢，真實性檢查可確認答案來自正確的解析器，原則決定是否回應，而匿名性則取決於誰營運該解析器。安全 Web 閘道 可能涵蓋該技術堆疊的更多部分，因此在承諾採用之前，請先比較這兩個角色的差異。

先從一個訪客 SSID 開始。記錄其裝置目前使用的解析器，接著在該網路上測試 Purple Shield，之後再將策略擴展至各個場地。