最佳 DNS filtering:企業綜合指南
本技術參考指南說明企業級 DNS filtering 如何在建立連線之前的解析層阻擋惡意網域,進而保護公共網路的安全。它為 IT 總監、網路架構師和場所營運團隊提供了保護餐飲旅宿、零售和公共部門環境中 Guest WiFi 所需的佈署架構、防火牆設定以及合規性背景。Purple Shield 在 DNS 層級為超過 80,000 個實體場所阻擋惡意軟體、殭屍網路和不當內容。
收聽此指南
查看播客逐字稿

執行摘要
對於管理大規模公共網路的 IT 領導者而言,維護安全的面網環境是運營的核心任務,而非可有可無的選項。在餐飲旅宿、零售和公共場所中的 Guest WiFi 本質上是一個不被信任的環境。如果缺乏強大的控制措施,它將成為惡意軟體分發、殭屍網路活動,以及存取不當內容的管道,進而損害品牌商譽並帶來合規風險。
DNS 過濾是在網路邊緣執行內容策略和阻擋威脅最有效率的機制。與耗費大量資源的深層封包檢測 (DPI) 不同,DNS 過濾在交換任何載荷數據之前,就先攔截了網域名稱解析請求。它會針對即時威脅情資評估輕量級的 UDP 封包,並返回有效的 IP 位址或沉洞 (sinkhole),這其中增加的延遲不到 2 毫秒。這使其成為服務數千台並行未託管裝置的高密度環境中,唯一可行且實用的內容控制方法。
本指南涵蓋在分散式企業場域中部署 DNS 過濾所需的技術架構,包括 VLAN 隔離、port 53 強制執行、Captive Portal 整合,以及防止 DNS over HTTPS (DoH) 規避。此外,本指南也探討了如何符合 PCI-DSS 和 GDPR 的合規性,並說明 Purple Shield 如何在不需更換硬體的情況下,直接與 Cisco Meraki、HPE Aruba、Ruckus、Juniper Mist、Ubiquiti UniFi、Cambium、Extreme Networks 和 Fortinet 等現有硬體架構無縫整合。
技術深度解析:DNS 過濾的運作原理
網域名稱系統 (DNS) 將人類易讀的網域翻譯成機器可讀的 IP 位址。每一次的網際網路連線都始於 DNS 解析請求。在標準網路中,裝置會查詢由 ISP 分配的預設解析器。在安全架構中,DHCP 伺服器則會為訪客 VLAN 上的裝置分配一個執行安全策略的 DNS 解析器。
當裝置查詢此安全解析器時,過濾引擎會同時針對多個數據源評估該網域:即時威脅情資來源、類別封鎖清單 (成人內容、賭博、盜版) 以及殭屍網路命令與控制 (C2) 網域登錄表。整個決策過程僅需數毫秒。
若網域安全無虞,引擎會返回正確的 IP 位址,連線照常進行。若網域被標記為惡意或違反您的可接受使用策略,引擎會返回一個無法路由的 IP 位址 (即沈洞化),或是將使用者重新導向至品牌專屬的封鎖頁面。關鍵在於:此攔截干預發生在裝置與目的伺服器進行任何數據載荷交換之前。

效能與規模優勢
對於高密度公共環境而言,DNS 過濾在架構上優於 DPI。DPI 需要網路硬體來檢查每個封包的負載。在擁有 50,000 名並行使用者的場域(例如體育場、會議中心或大型零售物業)中,DPI 會引入顯著的延遲,且每個檢查點都需要昂貴的專用硬體。
DNS 過濾在連線生命週期的起點運作。它僅評估單個輕量級 UDP 封包。一旦解析完成,數據就會直接在用戶端與目的地伺服器之間傳輸。過濾引擎絕不處理數據負載。無論並行使用者數量多少,延遲影響始終保持在 2 毫秒以下。
由於 DNS 過濾在連線建立之前運作,因此它與協定無關。無論應用程式使用的是 HTTP、HTTPS、FTP 還是自訂連接埠,它都能阻擋連線。這比僅檢查 HTTP/HTTPS 流量的網址型過濾具有顯著優勢。

提前 10 天的威脅偵測優勢
傳統的 DNS 安全依賴被動式黑名單:識別出惡意網域、回報給中央機構、新增到資料庫,最後分發到您的過濾器 - 這個過程可能需要數天。現代惡意軟體活動會利用這個時間差。攻擊者註冊新網域,在 24 小時內執行活動,並在該網域進入任何標準阻擋名單之前將其放棄。
Purple Shield 使用 AI 驅動的威脅偵測,即時分析網域註冊模式、IP 聲譽和密碼學簽章。與傳統的被動式供應商相比,此方法最多可提前 10 天識別並阻擋新興的零日威脅(Purple 內部數據,2026 年)。在訪客裝置上的單個惡意連結就可能導致勒索軟體的環境中,該偵測時間差在營運上至關重要。
實作指南:架構與部署
正確部署 DNS 過濾需要在三個層級進行精確的網路設定:DHCP、防火牆和 Captive Portal。
步驟 1:VLAN 區隔
區隔您的網路,將訪客流量與營運系統隔離。將訪客裝置放置在專用 VLAN(例如 VLAN 20)上,並將 POS 終端機、物業管理系統和員工裝置保留在具有內部 DNS 解析器的獨立 VLAN 上。這可確保您的 DNS 過濾原則僅套用於未受信任的訪客流量,且不會干擾營運系統。
此區隔同時也符合 PCI-DSS 規範 1.3 的要求,該規範要求將持卡人資料環境與未受信任的網路隔離。訪客 WiFi 絕不能與付款基礎設施共用 VLAN。
步驟 2:DHCP 範圍設定
針對訪客 VLAN 設定 DHCP 範圍,將您的雲端 DNS 過濾服務 IP 位址指派為主要與次要 DNS 伺服器。這可確保加入訪客網路的每台裝置都能自動取得正確的解析器。
步驟 3:在防火牆強制執行 Port 53 規則
單靠 DHCP 指派是不夠的。使用者可以透過手動將裝置設定為使用 Google (8.8.8.8) 或 Cloudflare (1.1.1.1) 等公用解析器,來覆蓋 DHCP 提供的 DNS 設定。惡意軟體也經常會硬編碼 DNS 設定,以完全繞過網路控制。
您必須實施一條防火牆規則,丟棄從訪客 VLAN 到您指定過濾伺服器以外任何 IP 位址之 Port 53(UDP 和 TCP)的所有外網流量。這會將 DNS 過濾從建議控制轉換為強制執行的控制。
步驟 4:DNS over HTTPS (DoH) 緩解措施
現代瀏覽器和應用程式越來越常使用 DoH,這會將 DNS 查詢加密在 Port 443 上的標準 HTTPS 流量中。這會完全繞過 Port 53 的攔截。為了維持防護覆蓋率,請設定您的防火牆,以封鎖主要 DoH 供應商的已知 IP 位址範圍。這會強迫用戶端裝置降級回標準的未加密 DNS,以便您的過濾引擎進行檢查。NIST SP 800-81r3(於 2026 年 3 月發布)特別針對企業 DNS 安全考量,探討了 DoH 的問題。
步驟 5:Captive Portal Walled Garden 設定
如果您使用 Captive Portal 進行訪客驗證,您必須在套用任何封鎖策略之前設定 Walled Garden(圍牆花園)。Walled Garden 是裝置在通過驗證前可以存取的網域清單。它必須包含 Captive Portal 運作所需的所有網域:您的 Portal 專屬網域、任何身分識別提供商(Microsoft Entra ID, Okta, Google Workspace),以及任何社群登入的 OAuth 端點。
如果這些網域在驗證前被封鎖,使用者將無法完成登入流程。其結果是中斷的登入體驗與挫折的訪客。請先設定 Walled Garden,然後僅對已驗證的連線工作套用您的內容過濾策略。
如需進一步瞭解 SSID 架構以及 Guest WiFi、Staff WiFi 和 IoT 網路應如何規劃,請參閱 管理一切的三個 SSID:guest、Passpoint 以及 IoT WiFi 。
最佳實踐:策略設計與持續管理
基於類別的封鎖
圍繞內容類別而非個別網域封鎖清單來建構您的 DNS 過濾策略。類別通常包括:惡意軟體與網路釣魚、Botnet 幕後控制、成人內容、賭博、非法串流媒體以及點對點檔案分享。基於類別的策略更容易維護,並能在威脅情資更新時自動捕獲新網域。
威脅情資更新頻率
選擇能在即時或近乎即時更新威脅情資的 DNS 過濾提供商。每日更新的靜態黑名單不足以抵禦現代的快速變遷惡意軟體活動。Purple Shield 會持續更新其威脅情資,反映出相同的 AI 驅動偵測技術,提供比被動反應型提供商領先 10 天的優勢。
硬體無關部署
Purple Shield 以雲端重疊(cloud overlay)方式運作,這意味著它能與您現有的無線基地台基礎設施整合,無需更換硬體。它與 Cisco Meraki、HPE Aruba、Ruckus、Juniper Mist、Ubiquiti UniFi、Cambium、Extreme 和 Fortinet 相容。過濾策略應用於 DNS 層,因此無線基地台硬體僅需將 DNS 查詢轉發至正確的解析器。
分析與報告
DNS 過濾會產生詳細的查詢記錄,提供網路行為的可視性。使用這些記錄來識別趨勢:來自特定無線基地台的已封鎖網路釣魚嘗試次數激增,可能表示存在針對性攻擊。定期審查已封鎖類別報告也支援合規性稽核,向 PCI DSS 評估員和 GDPR 稽核員證明您已實施主動控制措施。
Purple 的 WiFi Analytics 平台與 Shield 整合,為安全事件與網路效能提供統一的可視性。
疑難排解與風險緩釋
透過自訂 DNS 繞過過濾器
症狀:使用者回報可以存取本應被封鎖的內容。防火牆記錄顯示來自訪客 VLAN 的 DNS 查詢指向 8.8.8.8 或 1.1.1.1。
原因:防火牆未封鎖 Port 53。使用者正在覆寫 DHCP 指派的 DNS 設定。
解決方案:實施防火牆規則,丟棄所有從訪客 VLAN 到您過濾引擎以外之任何 IP 的連外 UDP/TCP Port 53 流量。
Captive Portal 驗證失敗
症狀:訪客無法完成登入流程。Captive Portal 網頁無法載入,或社群登入按鈕沒有回應。
原因:DNS 過濾器在驗證前封鎖了身分識別提供商的網域。Microsoft Entra ID、Google Workspace 或您 Portal 的專屬網域位於已封鎖類別清單中。
解決方案:稽核您的 Walled Garden 設定。將所有必要的驗證網域新增至驗證前允許清單中。在部署策略變更之前,先在預備環境中測試完整的登入流程。
DoH 繞過
症狀:儘管網路使用率很高,但 DNS 過濾器記錄顯示查詢量很低。某些裝置似乎完全繞過了過濾。
原因:瀏覽器或應用程式正在使用 DoH,透過 Port 443 將加密的 DNS 查詢路由到外部解析器。
解決方案:在防火牆封鎖主要 DoH 提供商的已知 IP 範圍。藉由監控指向已知 DoH 解析器 IP 的 HTTPS 連線來驗證防護範圍。
營運 VLAN 中斷
症狀:部署 DNS 過濾器後,POS 終端機或物業管理系統失去連線。
原因:DNS 過濾策略已套用到錯誤的 VLAN,或者 DHCP 正在將雲端 DNS 解析程式分配給營運設備。
修正方法:驗證所有交換器連接埠和無線存取點的 VLAN 標記。確認營運設備的 VLAN 已設定為僅使用內部 DNS 解析程式。
投資報酬率(ROI)與業務影響
DNS 過濾在三個維度上帶來了可衡量的回報。
頻寬回收:封鎖非法串流媒體、點對點分享(P2P)和自動化 Botnet 流量可回收大量頻寬。在飯店環境中,這可以將訪客 VLAN 的使用率降低 20 - 40%,在無需升級線路的情況下提升合法用戶的效能。
降低合規成本:證明具備主動的 DNS 層級控制可縮減 PCI DSS 評估的範圍和成本。它還為 GDPR 第 32 條(確保資料安全的技術措施)提供了文件化證據,並支持 Cyber Essentials 認證對惡意軟體防護的要求。
品牌與責任保護:在零售和餐旅環境中執行適合家庭瀏覽的策略,可防止公開展示不當內容。在服務兒童的場所(如購物中心、家庭旅館、體育場館),這既是品牌要求,也是許多司法管轄區的法律考量。
如需特定行業的部署指南,請參閱我們的行業頁面: Hospitality 、 Retail 、 Healthcare 以及 Transport 。
關鍵定義
DNS filtering
一種安全技術,在允許或阻止連接之前,攔截網域名稱解析請求並根據威脅情報來源與內容策略對其進行評估。
公共網路上未託管訪客裝置的主要內容控制方法。無需安裝終端代理程式。
Sinkholing
在回應惡意網域的 DNS 查詢時返回不可路由的 IP 地址(例如 0.0.0.0),從而阻止設備建立連接。
用於默默阻止殭屍網絡命令與控制流量,而不會提醒惡意軟體已被檢測到。
Walled Garden
一種受限的預先驗證網路環境,允許使用者在完成 captive portal 登入流程之前訪問一組特定的核准網域。
必須包含所有身分識別提供者網域(Microsoft Entra ID、Google Workspace、Okta)和 captive portal 資產,以防止身分驗證失敗。
DNS over HTTPS (DoH)
一種在連接埠 443 上的標準 HTTPS 流量中加密 DNS 查詢的協定,可防止網路層級的檢查獲悉目的地網域。
在現代瀏覽器中預設使用的比例越來越高。需要在防火牆層級阻止 DoH 提供者的 IP 範圍,以維持 DNS 過濾的覆蓋範圍。
VLAN segmentation
使用 802.1Q 標記將單個實體網路劃分為多個隔離的邏輯網路。
對於將訪客流量與營運系統隔離至關重要。PCI DSS 要求 1.3 規定,持卡人資料環境必須與包括訪客 WiFi 在內的不信任網路進行隔離。
Captive portal
設備在獲得完整網路存取權限之前必須與之互動的網頁,用於身分驗證、接受服務條款以及第一方數據收集。
需要仔細設定 Walled Garden,以便與 DNS 過濾協同工作。
Deep Packet Inspection (DPI)
一種網路過濾方法,在檢查點檢查封包的完整負載,以實現內容感知過濾,但會引入顯著的處理開銷。
由於延遲和硬體成本,在非高密度訪客網路中並不實用。DNS 過濾是非受控設備環境的首選替代方案。
Threat intelligence feed
一個持續更新的已知惡意 IP 地址、網域和 URL 模式的資料庫,用於支援即時 DNS 過濾決策。
威脅情報來源的品質和更新頻率決定了 DNS 過濾器對新零日威脅的反應速度。
Zero-day domain
在惡意軟體或網路釣魚活動中使用的新註冊網域,且尚未出現在任何標準阻止清單中。
現代攻擊活動使用活動時間不超過 24 小時的一次性網域。AI 驅動的威脅檢測透過分析註冊模式來識別這些網域,而不是等待報告。
範例
一家擁有 400 間客房的連鎖酒店正在 12 個物業佈署 Guest WiFi。他們使用 Microsoft Entra ID 進行 Captive Portal 驗證,且其物業管理系統 (PMS) 運行在同一個實體交換器架構上。啟用 DNS filtering 後,三個物業的房客回報無法完成登入流程。根本原因是什麼?團隊應如何解決?
根本原因是 Walled Garden 設定不完整。DNS 篩選器在房客驗證之前阻擋了 Microsoft Entra ID 驗證網域,導致房客無法載入登入頁面的惡性循環。解決步驟:1. 在 DNS filtering 儀表板中,建立一個預先驗證原則,明確將所有 Microsoft Entra ID 網域列入白名單,包括 login.microsoftonline.com、login.live.com 以及任何租戶專用網域。2. 確認 Captive Portal 自身的網域及其載入的任何 CDN 資產也已列入白名單。3. 確認 PMS VLAN (VLAN 10) 設定為使用內部 DNS 解析器,而非雲端篩選引擎。4. 僅對訪客 VLAN (VLAN 20) 上的驗證後工作階段套用限制性內容阻擋原則。5. 在關閉事件之前,在每個受影響的物業測試完整的登入流程。
一家大型連鎖零售商經營著 200 家門市,每家門市都有訪客 WiFi 網路。其 IT 安全團隊佈署了雲端 DNS 篩選器,並更新了所有訪客 VLAN 的 DHCP 範圍。兩週後,滲透測試顯示 18% 的訪客裝置成功解析了已知的惡意網域。DNS 篩選器記錄顯示沒有來自這些裝置的被阻擋查詢。架構上的缺陷是什麼?解決方法是什麼?
缺陷在於防火牆上未阻擋 Port 53。這 18% 的裝置透過使用硬編碼解析器(8.8.8.8、1.1.1.1)或使用 DNS over HTTPS 繞過了 DHCP 指派的 DNS 伺服器。由於他們的 DNS 查詢從未到達篩選引擎,因此記錄中不會出現被阻擋的查詢。解決方法:1. 在訪客 VLAN 閘道器上實施防火牆規則,丟棄所有指向核准篩選引擎 IP 之外任何 IP 的 Port 53 輸出 UDP 和 TCP 流量。2. 在防火牆阻擋主要 DoH 供應商(Cloudflare、Google、NextDNS)的 IP 範圍,以防止加密繞過。3. 重新執行滲透測試以確認覆蓋範圍。4. 監控 Port 53 流量的防火牆丟棄記錄,以確認規則已啟用。
練習題
Q1. 某家零售連鎖店在 150 家分店部署了雲端 DNS 過濾器。他們更新了所有訪客 VLAN 上的 DHCP 範圍,以分配過濾引擎的 IP。一週後,分店經理回報顧客仍然可以存取被阻止的內容類別。DNS 過濾器儀表板顯示來自這些分店的查詢量非常低。最可能的起因是什麼?該如何解決?
提示:考慮設備如何在不使用 DHCP 分配的伺服器的情況下解析 DNS。
查看標準答案
最可能的起因是防火牆上未阻止輸出連接埠 53。設備正在使用硬編碼的公共解析器覆蓋 DHCP 分配的 DNS 伺服器。儀表板中極低的查詢量證實了查詢未到達過濾引擎。解決方法是實施一條防火牆規則,丟棄從訪客 VLAN 發往核准過濾引擎 IP 以外之任何 IP 的連接埠 53 上的所有輸出 UDP 和 TCP 流量。此外,阻止已知的 DoH 提供者 IP 範圍,以防止繞過加密的 DNS。
Q2. 一間會議中心正首次部署 DNS 篩選。他們使用 Google Workspace 進行 Captive Portal 上的與會者身分驗證。在測試期間,與會者無法完成登入流程,因為 Google 登入頁面無法載入。請問遺漏了哪個設定步驟,應該如何修正?
提示:身分驗證發生在設備獲得完整網路存取權限之前。在身分驗證完成之前,必須可以連訪哪些網域?
查看標準答案
在套用 DNS 篩選策略之前,未設定 Walled Garden。DNS 篩選在與會者進行身分驗證之前,阻擋了 Google Workspace 驗證網域(accounts.google.com、oauth2.googleapis.com)。修正方法是將所有必要的 Google Workspace OAuth 和驗證網域新增到 DNS 篩選策略中的驗證前允許清單。Captive Portal 的專屬網域以及任何 CDN 資源也必須加入允許清單。限制性的內容策略應僅套用於驗證後的連線階段。
Q3. 一個體育場的 IT 團隊正在評估其容納 60,000 人的場地應採用 DNS 篩選還是深層封包檢測 (DPI)。網路團隊擔心尖峰活動期間的延遲問題。哪種方法更合適,為什麼?
提示:請考慮在 60,000 名同時在線使用者的規模下,每種方法所產生的處理開銷。
查看標準答案
DNS 篩選是合適的選擇。它在解析層運作,在建立任何連線之前評估單個輕量級 UDP 封包,無論同時在線使用者人數多少,增加的延遲都低於 2 毫秒。DPI 則需要檢測每個封包的完整負載,在 60,000 名同時在線使用者下,這會引入顯著的延遲,並且在每個檢測點都需要極其昂貴的硬體。DNS 篩選也與協定無關,可阻擋任何連接埠上的連線,而 DPI 通常僅限於 HTTP 和 HTTPS 流量。
Q4. 一家飯店集團的 IT 總監希望確認其 DNS 篩選部署是否符合 PCI DSS 要求。他們的付款終端設備位於 VLAN 10,而訪客 WiFi 則位於 VLAN 20。DNS 篩選僅套用於 VLAN 20。他們應該為 PCI DSS 評估員記錄哪些額外的佐證資料?
提示:PCI DSS 規範 1.3 涵蓋了受信任與不受信任網路之間的網路存取控制。
查看標準答案
IT 總監應記錄:1. 確認無法從 VLAN 20(訪客網路)存取 VLAN 10(持卡人資料環境)的防火牆規則,以滿足 PCI DSS 規範 1.3。2. 顯示 VLAN 10 裝置使用內部 DNS 解析器而非雲端篩選引擎的 DHCP 設定。3. 在防火牆阻擋從 VLAN 20 到未授權 IP 的輸出連接埠 53 的規則,以證明強制執行 DNS 篩選。4. 顯示在 VLAN 20 上啟用惡意軟體和傀儡網路阻擋類別的 DNS 篩選策略文件。5. 顯示已阻擋查詢事件的 DNS 篩選記錄,以證明該控制措施處於作用中並受到監控。
繼續閱讀本系列
如何安全地隔離員工與訪客 WiFi 網路
本權威技術指南為 IT 領導者提供實用的策略,利用 VLAN 與 802.1X 安全地隔離員工、訪客及 IoT WiFi 網路。內容詳細說明如何保護企業基礎架構、維護 PCI DSS 合規性,並利用 captive portals 收集第一方數據。
深入理解 Cisco SUDI:安全網路存取控制中的硬體錨定身分驗證
本指南說明 Cisco SUDI 如何為企業網路基礎設施提供硬體錨定且具密碼編譯安全性的身分。了解如何以不可變的 802.1AR 憑證取代易遭偽造的 MAC 位址,以確保您場域的網路存取控制安全。
如何設定 SCEP 以實現自動化企業級 WiFi 憑證註冊
本指南說明如何設定 SCEP(簡單憑證註冊協定)以實現自動化企業級 WiFi 憑證註冊,涵蓋從 PKI 和 NDES 到 MDM 設定檔部署以及 RADIUS 驗證的完整架構。本指南專為飯店、零售連鎖店、體育場館、會議中心和公共部門組織的 IT 經理、網路架構師和 CTO 所設計,旨在協助他們淘汰預先共用金鑰,並實作具擴充性、基於身分識別的 802.1X EAP-TLS 驗證。Purple 獨立於硬體的雲端重疊平台可直接與此架構整合,提供與憑證驗證員工網路並行的訪客和 BYOD WiFi 層。