保護性 DNS 解析：工作原理與重要性
Published
飯店大廳的訪客點擊了一個連結，頁面開始載入。在瀏覽器連線至網站之前，訪客的裝置需要先找出該表網站在網際網路上的位址。這個寧靜的查詢過程，正是檢查是否允許存取該目的地的絕佳時機。
保護性 DNS 為這個常規步驟增加了安全性決策。它可以協助企業組織保護共享網路上的使用者與設備，但前提是他們的流量必須使用託管解析器。瞭解這一點差異，可以更輕鬆地針對效能、例外狀況、旁路路由和隱私進行規劃。
目錄
- 為什麼每一次造訪網站都始於 DNS 查詢
- 防護型 DNS 在名稱解析階段的作用
- 原則強制執行如何在整個網路中運作
- 效能影響與可衡量的頁面載入提升
- 場館與企業的真實應用案例
- 為您的網路選擇合適的方法
- 超越封鎖次數，衡量防護型 DNS 的價值
- 規劃防護型 DNS 部署的下一步
為什麼每次造訪網站都要從 DNS 查詢開始
網站名稱對人們來說很容易記住。但電腦需要網路位址才能建立連線。網域名稱系統 (DNS) 提供了這種轉換服務，就像電話簿將人的姓名轉換為可以撥打的號碼一樣。
當訪客點擊連結時，瀏覽器會向 DNS 解析器詢問該網站名稱對應的位址。解析器查到答案後傳回，瀏覽器便能嘗試連線至目的地。DNS 本身並不傳送頁面內容，但能協助裝置找到去哪裡請求內容。
該順序建立了一個有用的安全性檢查點。如果解析器將要求的網域識別為已知威脅，它可以在瀏覽器連線之前拒絕提供可用的答案。保護性 DNS 服務會在此查詢階段套用安全性策略，而不是等待下載檔案或端點上出現可疑行為。
實際差異：DNS 協助裝置找到目的地。保護性 DNS 則增加了關於尋找是否應該成功的決策。
這在許多人和設備共用網路基礎架構的場所尤為重要。例如飯店內可能會有賓客的手機、員工的筆記型電腦、支付終端機以及連網的大樓設備，各自使用同一個整體網路的不同部分。辦公室、住宅物業或公共場館也面臨類似的挑戰，只是使用者與設備有所不同。
防護型 DNS 可以為這些查詢提供統一的檢查點，但它並不是一套完整的資安方案。它無法保護避開受控解析器的裝置，也無法取代端點防護、存取控制或嚴謹的網路設計。真正有用的問題在於解析器如何做出決策、企業如何確保裝置持續走在預期的路徑上，以及有哪些證據能證明該服務在發揮作用的同時不會造成業務中斷。
保護性 DNS 在名稱解析階段的作用
保護性 DNS 是一種執行原則的遞迴解析器。遞迴解析器代表裝置處理請求，而保護性 DNS 則套用規則來決定所請求的目的地是否應該收到正常的 DNS 回應。它不僅僅是速度更快或經過加密的 DNS。
從頭到尾完整追蹤一次查詢：
- 裝置請求網域名稱。瀏覽器、應用程式或其他程序在嘗試連線到指定目的地之前，需要取得位址。
- 解析器檢查請求。解析器會比對網域與已設定的策略及威脅情報。更強大的實作方式還可以檢查解析後的 IP 位址，這有助於評估網域背後的基礎設施。
- 解析器回傳結果。如果策略允許該請求，解析器會提供解答。如果不允許，服務可以封鎖解析、回傳空回應，或將用戶端重新導向至警告頁面。確切的行為取決於產品與策略。
某些實作方式會尋找演算法生成的網域（DGA），惡意軟體可用此尋找命令與控制（C2）基礎設施。網域字元中的異常模式（包括高熵值）可作為進一步進行策略評估的訊號。這類分析能補足威脅情報情資，但企業仍需驗證其選擇的服務如何處理偵測與例外情況。
加密與真實性並不等同於安全性決策
DNSSEC 有助於驗證已簽署 DNS 資料的完整性與真實性。DNS over HTTPS (DoH) 和 DNS over TLS (DoT) 則在傳輸過程中保護 DNS 查詢。這些特性固然重要，但它們本身並不能判定存在的網域是否為惡意網域。保護性 DNS 會在解析器端做出該策略決策。
對於正在審查網路存取與雲端服務控制項的團隊而言，此區別可以與更廣泛的 保護 Microsoft 365 企業環境安全 指引結合考量。重點在於避免將加密傳輸或已驗證的資料視為目的地風險決策的替代品。
政策執行如何在整個網路中運作
即便解析器能對單一請求做出正確判斷，但如果裝置能繞過它來傳送 DNS，依然無法保護整個網路。因此，跨園區的部署關鍵在於兩件相互關聯的事：一致的原則與前往解析器的可靠路徑。
集中式設計會將來自多個站點的 DNS 請求傳送到託管服務。這使得在不同地點套用共享規則與審查活動變得更容易。這也讓可用性成為一項安全性要求。如果解析器無法連線，即使網路的其餘部分正常運作，一般的 Web 存取和依賴 DNS 的服務也可能會失敗。
美國政府的保護性 DNS 服務於 2022 年 9 月開放給聯邦民事行政部門機構使用。截至 2024 年 8 月，已有超過 104 個機構加入，每天平均產生 16 億次安全的 DNS 查詢；該計畫報告了 99.999% 的解析器正常運行時間（CISA 的保護性 DNS 事實清單）。營運上的經驗教訓是，過濾品質與服務可用性需要一起進行評估。
套用身分識別，無需倍增策略
員工、訪客、住戶以及連線設備不一定需要相同的規則。網路可以根據身分或網路區段指定不同的策略，例如員工網路、訪客 WiFi 以及用於建築物設備的隔離網路。目標是在保持管理便利性的同時，讓策略符合使用者或設備的需求。
存取控制有助於建立這種隔離，而網路流量監控則可協助團隊 調查異常的網路活動。如需瞭解網路存取控制如何融入受管理環境的相關觀點，請參閱這些 網路存取控制解決方案。
刻意關閉繞過路徑
如果裝置可以直接將一般 DNS 傳送到外部解析器，保護性服務可能永遠不會收到該請求。DoH 與 DoT 帶來了另一個挑戰：加密雖然能在傳輸過程中保護查詢，但未受管理的解析器也可能使這些查詢脫離組織的原則與可視性。
在需要進行強制執行的情況下，團隊應識別直接 DNS 路徑與未授權的加密 DNS 目標，然後決定網路、端點與瀏覽器控制項將如何處理這些狀況。同時也要測試例外情況。Captive Portal、行動裝置、IPv6 以及擁有自我解析器設定的應用程式，其行為可能與企業網路中受控的筆記型電腦不同。策略僅能在企業可管轄的路徑上發揮作用。
效能影響與可衡量的頁面載入速度提升
保護性 DNS 服務並不一定會讓瀏覽速度變得明顯遲緩。其影響程度較少取決於過濾動作本身，而是取決於實際的設計選擇：解析器所在的位置、快取回應的方式、維護連線的方式，以及裝置是否會繞過解析器。
當連線需要在傳送查詢之前建立 TCP、TLS 或 HTTP 時，加密的 DNS 可能會增加設定時間。重用持久性工作階段可以避免重複進行大部分設定。根據 加密 DNS 效能的獨立測量結果，TLS 1.3、0-RTT、HTTP/2 多路複用與 QUIC 也可以減少連線開銷。在良好的網路條件下，原始查閱延遲可以忽略不計，但並非每個用戶端或網路路徑都能得到保證。
測試查詢，而不只是測試展示次數
就近且高可用性的解析器以及符合標準的快取機制，有助於保持一般查詢的快速回應。然而，單一平均延遲數據可能會掩蓋少數使用者的緩慢體驗，或是掩蓋解析器必須擷取尚未快取之答案時的延遲狀況。
分別針對冷快取與熱快取測量 p50、p90 與 p99 查詢延遲。中位數代表典型的查詢狀況；較高的百分位數則能呈現可能更嚴重影響使用者的較慢情況。請將查詢速度與完整頁面載入時間區隔開來，因為 DNS 只是瀏覽器存取過程中的其中一環。
納入容易引發意外狀況的測試條件
請使用人們實際使用的網路和裝置類型進行測試，包括行動用戶端、IPv6 和 Captive Portal。檢查可能選擇自行使用 DoH 或 DoT 服務的應用程式與瀏覽器，因為它們可能會同時改變 DNS 請求的路徑與能見度。
根據分散式測量的觀察，DoQ (DNS over QUIC) 的效能已接近明文傳輸，且在某些頁面載入案例中優於 DoH。請將此類結果視為在您自身環境中測試傳輸選擇的理由，而非特定結果的保證。實際目標是具備鄰近的解析器、有效的快取、可重複使用的加密工作階段，以及不會留下未管理開放路徑的架構設計。
場域與企業中的實際應用案例
全國性的部署展示了當許多組織共用一個託管安全層時，保護性 DNS 所能發揮的作用。在英國，使用保護性功能網域名稱系統服務的組織數量從 2022 年的 944 家增加到 1,173 家，成長了 24%。在那一年中，該服務處理了約 0.55 兆次 DNS 查詢，並攔截了 110 億次與惡意目的地相關的請求，約佔所有查詢的 2%（英國 NCSC PDNS 摘要）。
該規模說明了在嘗試連線前就做出決策的價值。這並不代表每個被阻擋的請求都會演變成安全事件，也不代表單靠 DNS 就能阻擋通往威脅的所有途徑。對於多據點營運商而言，有用的比較基準在於該服務能否一致地套用策略、產生具可操作性的遙測資料，並處理該環境的傳輸量與例外情況。
請考量同一個檢查點如何套用至不同的場域：
- 飯店與住宅物業：將訪客或住戶存取權與員工及建築設備區隔開來。 Captive Portal、較舊的裝置或住戶偏好的加密解析器都可能產生需要事先規劃的例外狀況。
- 機場與體育場館：在高流動率的公共存取中套用統一的基準，同時保持營運與員工網路獨立。請留意未管理裝置以及需要紀錄例外狀況的連線需求。
- 醫療照護與教育機構：限制存取有害目標，同時不封鎖用於照護、教學或行政的合規服務。當原則封鎖了工作所需的內容時，提供明確的審查途徑。
- 零售與購物中心：將顧客流量與收銀機、員工裝置及其他營運設備區隔。規劃訪客存取權的零售團隊在思考存取權與原則如何搭配時，也可以參考這些 零售 WiFi 解決方案。
對此主題進行簡短介紹，也有助於團隊針對 DNS 層的作用與侷限達成共識：
在各種情境中，DNS 過濾都是一種部分控制項，而非保證能阻擋所有威脅。使用者仍可透過其他解析器或直接使用 IP 位址連至基礎架構，應用程式也可以使用不依賴組織 DNS 路徑的協定。因此部署時除了策略本身之外，還需要具備例外處理與監控機制。
為您的網路選擇最合適的方案
保護性 DNS 是在解析器端運作。端點代理程式、瀏覽器設定與網路控制項則在不同節點運作，因此團隊通常會選擇多種機制組合，而非單一替代方案。最佳組合取決於由誰管理裝置、網路能看到哪些流量，以及該如何處理例外狀況。
| 控制措施 | 最適合情境 | 可視性 | 常見局限性 |
|---|---|---|---|
| 保護性 DNS | 共用網路、受控管設備資產與 DNS 策略執行 | 通過解析器的 DNS 請求 | 未受控管的解析器與非 DNS 路徑可繞過此控制 |
| 端點 Agent | 需要在網路外獲得保護的受控管筆電與行動裝置 | 已安裝 Agent 可見的活動 | 覆蓋範圍取決於 Agent 的安裝、健康狀況與管理狀態 |
| 瀏覽器策略 | 可治理解析器與瀏覽設定的受控管瀏覽器 | 瀏覽器設定與所選的瀏覽器活動 | 無法治理所有應用程式或未受控管的瀏覽器 |
| 網路層級控制 | 分段網路與通過受控管基礎設施的流量 | 控制措施覆蓋範圍內的網路流量 | 加密流量或網路外流量可能會限制檢查能力 |
| 身分與存取控制 | 具有不同存取需求的員工、訪客、住戶與裝置群組 | 與身分或分段綁定的連線及存取決策 | 允許的連線本身無法判斷每一個目的地的安全性 |
對於受管理的筆記型電腦，端點與瀏覽器控制項可以補充解析器策略，特別是在員工於辦公室外工作時。賓客 WiFi 與 BYOD 較難透過 Agent 進行管理，因此在組織能將 DNS 引導至所選服務的前提下，網路端控制項更為實用。IoT 與家用設備通常需要進行網路隔離，並制定考量到有限設備管理選項的策略。
對於正在比較網路身分、過濾機制與面向使用者之檢查機制的團隊來說，來自 mailX 的免費 DNS 與電子郵件檢查工具 可作為全面檢視存取控制時的相關資源。如果管理範圍包含付款環境，也請考量 WiFi 設計與 PCI-DSS 符合性需求 如何影響網路隔離與管理。
Purple Access 在現有存取點上結合了開放、安全與 xPSK 網路選項，並具備 Captive Portal 導引與身分識別導向的網路指派功能。Purple Shield 透過個別策略控制增加了保護性 DNS 與內容過濾功能。這些功能可以與端點及瀏覽器控制項並行，但並不能免除定義解析器強制執行、例外情況與監控的需求。請根據您需要保護的路徑和裝置選擇工具，然後驗證其策略是否能夠協同工作。
超越封鎖次數：如何衡量保護性 DNS 的價值
已封鎖的查詢總數僅代表解析器採取了行動。這本身並不能告訴您它是否攔截了正確的請求、是否干擾了正常的工作，或是漏掉了走其他路徑的流量。統計決策次數，但請衡量實際控制效果。
歐洲網際網路產業協會的 DNS 工作坊報告指出，前六個月共收到 230 萬件濫用報告，涵蓋 78 萬個不重複網域，每月報告數量從 22 萬件增加至 38 萬件（工作坊報告）。這些數字顯示了已通報濫用的規模。它們無法證明解析器阻止了多少事件、攔截是否正確，或者受影響的流量是否透過 VPN、替代解析器、硬編碼 IP 地址或加密應用程式協定到達了目的地。
圍繞成果與異常狀況建立計分卡
有價值的審查結合了安全性、服務品質與營運回應。追蹤解析器是否偵測到已知的惡意網域、團隊處理誤報申訴的速度，以及策略變更是否及時到達預期地點。將這些衡量指標與解析器可用性以及中位數和尾部查詢延遲相搭配。
同時也要衡量規避嘗試。封鎖請求數量偏低可能代表環境中的惡意活動較少，但也可能代表裝置未使用防護解析器。將相關事件與網路身分（例如 SSID、VLAN、場地或使用者群組）進行關聯，以便調查人員了解策略在何處適用，以及例外情況可能隱藏在何處。請將 DNS 活動與端點或事件資料進行比對，而不是宣稱每個被封鎖的查詢都代表成功阻止了一起事件。
將 DNS 記錄視為敏感的營運資料
DNS 紀錄可能會揭露瀏覽模式，這在醫療照護、教育、旅宿和住宅環境中需要特別謹慎。請設定保留限制、按角色限制存取權限，並將安全性遙測資料與訪客行銷資料分開。在大規模收集紀錄之前，先確定誰可以調查安全性事件以及他們需要哪些資料。
規劃防護性 DNS 部署的下一步
請從路徑開始，而不是儀表板。繪製哪些設備使用託管解析器、識別直接 DNS 或未授權的加密 DNS 可能在哪裡繞過解析器，並決定如何對企業組織未管理的設備進行執法。請包含針對策略封鎖之合法服務的例外處理流程。
在全面上線前，請先就團隊將如何評估資安與服務品質達成共識：
- 確認解析器使用情況：檢查受控管裝置、訪客網路以及如 IoT 等較難預測的裝置。
- 測試網路路徑：在需要強制執行的部分，審視直接 DNS 與未授權的加密 DNS 路由。
- 衡量效能：比較冷快取與熱快取的查詢延遲，包含較慢的百分位數。
- 定義計分卡：追蹤誤報處理、可用性、策略傳播、繞過嘗試以及事件結果。
- 設定隱私規則：在開始大規模收集之前，建立日誌存取與保留邊界。
對於多據點部署，請召集網路與資安團隊，一同規劃身分、網路區段、解析器路由以及每個場地所需的例外情況。Purple 提供由網路工程師主持的設計會議，以塑造並驗證部署計畫。防護型 DNS 能讓透過受控查詢路徑到達有害目標變得更加困難，但它無法取代端點安全、網路隔離或隱私治理。
Purple Access 支援開放、安全與 xPSK WiFi 網路，並能透過現有的基地台進行基於身分的網路分配，以及訪客或 BYOD 存取設定。若要規劃這些存取控制如何與保護性 DNS 共同在您的據點發揮作用，請造訪 Purple Access。
