ExplainerDNS filtering limits
DNS 過濾的故障開放與故障關閉比較：當過濾器故障時會發生什麼事
您將能夠決定當 DNS 過濾器停止回應時，訪客與員工的 WiFi 應如何運作，並檢查您的網路是否真正實現故障關閉。您將了解備援機制隱藏在 DHCP、轉發器和設備中的位置，以及如何在停機事件考驗您之前先行測試備援能力。
DNS 過濾的故障開放 (Fail open) 與故障關閉 (Fail closed)，是指當網路的過濾解析器停止回應時所採取的處理機制。故障開放會切換至未經過濾的解析器，因此瀏覽可以繼續，但失去保護。故障關閉則不會將查詢傳送至其他地方，符合 NIST SP 800-53 控制措施 SC-24 (在已知狀態下故障) 的規範，因此沒有任何內容能在未經過濾的情況下進行解析。
什麼是 DNS 過濾故障開放與故障關閉？
DNS 過濾位於每次連線的第一步。在建立任何會話之前，手機會要求解析器將功能變數名稱轉換為 IP 位址 (RFC 1035)。保護性 DNS 解析器會根據威脅情報和您的內容策略檢查該名稱，然後傳回真實位址、封鎖頁面位址或拒絕回應。
這個部署位置正是 DNS 過濾發揮作用的原因。檢查會在單一封包到達目的地之前發生。它可以阻止社交工程釣魚連結或惡意軟體回呼，而防火牆只會將這些活動視為連接埠 443 上允許的流量。英國國家網路安全中心為公務機關運作的 Protective DNS 服務 也是基於相同的原則。
這個部署位置同時也是弱點所在。如果每次查詢都依賴過濾解析器，您就需要制定無法連線時的應變計畫。計畫只有兩種：
- 故障開放。 網路或裝置將查詢傳送到另一個不套用任何策略的解析器。瀏覽可以繼續進行，但保護、記錄和內容規則會暫停，直到過濾器恢復運作為止。
- 故障關閉。 不存在未經過濾的路徑。新的查詢會等待過濾解析器回應，在沒有策略決定的情況下，任何內容都無法解析。
這項選擇是在可用性與安全性之間取得平衡。故障開放有利於希望立即載入頁面的訪客。故障關閉則有利於您的資安團隊、防護負責人與審計人員，因為他們需要證明網路在一年中的每一分鐘都受到過濾保護。
NIST SP 800-53 Rev. 5 在兩個控制措施中提出了相同的概念：SC-24 為「在已知狀態下故障」，而 SC-7(18) 為「故障安全」(NIST SP 800-53 Rev. 5)。
過濾器故障行為在解析器端如何運作？
決定過濾器故障行為的是您的設定，而不是過濾器本身。設定會在三個地方進行：DHCP、任何本機 DNS 轉發器以及裝置本身。
DHCP DNS 欄位
DHCP 是在裝置加入時為其提供 IP 位址和網路設定的協定。大多數訪客和員工網路都使用它來為每台裝置提供兩個以上的 DNS 伺服器位址。如果所有位址都指向過濾解析器，則架構為故障關閉。如果第二個位址指向 ISP 或公共解析器，無論過濾廠商承諾為何，該架構都會變為故障開放。
流程圖顯示訪客裝置查詢在過濾解析器逾時，退回到未過濾的次要解析器，並在沒有策略檢查的情況下連線至網域。
Connections
- 訪客裝置 to 過濾解析器 (1. 在連接埠 53 進行查詢)
- 過濾解析器 to 訪客裝置 (2. 逾時，無回應)
- 訪客裝置 to 未過濾的備援解析器 (3. 重試次要解析器)
- 未過濾的備援解析器 to 未經策略檢查的回應 (4. 解析任何網域)
- 未經策略檢查的回應 to 連線建立 (5. 裝置連線)
本地轉發器
許多防火牆與閘道器都會執行 DNS 轉發器。裝置查詢閘道器，閘道器再轉發給上游解析器。在此情況下，備援機制存在於轉發器的上游清單中。若轉發器在過濾器下方列出了公用解析器，即使 DHCP 設定看起來沒問題，仍然會發生故障開放 (fail open)。
裝置自身的行為
解析器的選擇因作業系統而異。某些裝置會將第二個伺服器視為嚴格的備援。其他裝置則會在第一個伺服器回應過慢時查詢第二個伺服器，或同時向兩者發送查詢。因此在故障開放架構中，即使過濾器完全正常運作，未過濾的回應仍可能洩漏出去。
故障關閉 (Fail closed) 的運作方式
在故障關閉架構中，裝置或轉發器可使用的每個 DNS 位址，都會指向具有相同策略的過濾解析器。若其中一個停止回應，裝置會向下一個進行重試。只有在所有過濾解析器皆無法連線時，查詢才會失敗。此時裝置會收到逾時或 SERVFAIL (標準 DNS 「伺服器失敗」回應)，而非未過濾的回應。
流程圖顯示裝置在第一個過濾解析器失敗後重試第二個過濾解析器、策略允許或阻擋該網域，以及所有解析器皆失敗且未建立連線的虛線路徑。
Connections
- 裝置 to 過濾解析器 1 (1. 查詢)
- 裝置 to 過濾解析器 2 (2. 重試下一個過濾器)
- 過濾解析器 2 to 策略檢查 (3. 套用網路策略)
- 策略檢查 to 安全回應 (4a. 網域已允許)
- 策略檢查 to 阻擋回應 (4b. 威脅或已阻擋類別)
- 裝置 to 無回應 (若所有過濾器皆失效)
如果實作得當，故障關閉 (Fail closed) 並不脆弱。其復原力來自備援過濾解析器，而非未過濾的逃生口。
故障開啟 (Fail open)、故障關閉 (Fail closed)、故障安全 (Fail secure)：哪些術語容易混淆？
供應商文件、稽核結果與變更單中常出現四個相近的術語。它們描述不同的事物，混淆這些術語會導致錯誤的設計。
| 術語 | 描述內容 | 過濾器服務中斷期間 | 帶來的風險 |
|---|---|---|---|
| Fail open | 當無法連線至過濾器時，查詢會回退至未過濾的解析器 | 繼續瀏覽，但未經過濾 | 資安脅迫與已封鎖的類別將在無策略約束且通常無日誌的情況下被解析 |
| Fail closed | 僅設定過濾解析器，沒有未過濾的回退機制 | 在過濾解析器回應之前，新的尋找皆會失敗 | 可用性取決於過濾器的備援機制 |
| Fail secure (NIST SC-7(18)) | 控制架構術語：邊界設備在發生故障時絕不能進入不安全狀態 | 實務結果與 fail closed 相同 | 稽核人員可能會要求您提供相關證明 |
| Serve-stale (RFC 8767) | 當無法連線至上游伺服器時，解析器會從過期的快取中進行回應 | 近期存取的網域可繼續解析 | 回應反映的是最後一次的決策，而非全新的策略檢查 |
| Default deny | 針對過濾器尚未分類的網域所採用的策略 | 非故障模式；在過濾器健康運作時適用 | 若設定過於嚴格可能會導致過度封鎖 |
| Bypass | 設備透過寫死的 DNS、DoH 或 DoT 忽略網路解析器 | 不受影響，因為它一直都是未過濾狀態 | 需要出口控制，而非故障設定 |
Fail closed 並非 default deny
Default deny 是針對未分類網域的策略選擇。它是在過濾器正常運作時執行的。Fail closed 則是關於過濾器不存在或無法連線時會發生的狀況。您可以在採用寬鬆策略的同時執行 fail closed，也可以在採用嚴格策略的同時執行 fail open。
Serve-stale 介於兩者之間
RFC 8767 允許解析器在無法連線至上游伺服器時，從過期的快取中進行回應。這能讓熱門名稱 短期中斷期間維持運作。它會重播最後一次的決策，因此若某個網域在此之後變成惡意網域，將無法被攔截。
Bypass 並非故障
使用 DNS over HTTPS (DoH, RFC 8484) 或 DNS over TLS (DoT, RFC 7858) 連線至公共解析器的設備，完全不會觸及您的過濾器。Fail closed 設定對此無能為力。您必須透過出口規則來處理 bypass。
實務上會在何處遇到 DNS 過濾中斷？
僅有在網際網路連線正常但無法連線至過濾器時，DNS 過濾中斷才有影響。如果整個上行線路斷線，兩種模式看起來都一樣。在實務中，這種差距通常會透過日常營運事件而顯現：
- 防火牆變更封鎖了前往過濾器位址的外向連接埠 53；
- 本地轉發器崩潰或停止向上游轉發；
- 分支機構 WAN 上的路由變更導致 DNS 傳送至錯誤方向；
- 承包商編輯 DHCP 範圍並以「為了展現復原力」為由新增公共解析程式；
- 過濾服務提供者本身發生事件。
在 fail closed 網路上，這些看起來都無害。但在 fail open 網路上，每一項都會在不知不覺中解除保護。
旅宿業訪客網絡
飯店與酒吧集團套用內容原則，以確保訪客 WiFi 適合家庭使用且免受惡意軟體侵害。fail open 的訪客網絡會在不通知任何人的情況下直接放棄該原則。對於大型旅宿業者來說，公共 WiFi 的原則失效不僅帶來資安風險，還會帶來品牌風險。
醫療照護
Shield 每週在 St George's Healthcare NHS Trust 阻擋約 241,000 個威脅。根據我們的計算，平均每小時約 1,400 個。一小時的 fail open 空窗期就會讓這些查詢在病患、訪客和員工的裝置上未經檢查即完成解析。
交通樞紐
機場的公共網絡連結著數千台旅客裝置，其中許多是未受管理的裝置。在航廈中，fail open 的缺口意味著在高峰流量時出現未經過濾的公共網絡。
員工與企業網絡
員工網絡提升了可用性的要求。商業應用程式必須保持運作，因此 fail closed 後方需要真正的冗餘機制。內部名稱通常會在內部 DNS 伺服器上解析，然後將外部查詢轉發至過濾器。請確保該轉發層同樣沒有未經過濾的上游。
fail closed DNS 的限制與極端情況有哪些？
對大多數訪客和員工 WiFi 來說，fail closed 是正確的預設設定。但它仍有局限性，在圍繞它進行架構設計之前，您應該先了解這些限制。
僅配置單一解析程式的 fail closed 實質上是斷線計畫
如果網絡僅列出單一過濾地址，fail closed 意味著該地址的每一次斷線都會導致 DNS 癱瘓。在多個過濾解析程式之間建立冗餘，才能讓 fail closed 切實可行。請向您的提供者詢問您可以設定多少個解析程式地址，並對每一個進行測試。
快取能維持部分名稱運作
每個 DNS 回應都包含 TTL (Time to Live，快取存活時間)，即裝置或解析程式可以快取該回應的秒數。在短暫的斷線期間，已快取的名稱可繼續運作，而新名稱則會失敗。訪客會將此情況視為「某些網站可以打開，其他網站不行」，這可能會誤導您的服務台。
Captive Portal 在登入前需要 DNS
Captive Portal 是訪客上網前看到的登入頁面。裝置必須在驗證前解析 Portal 及任何圍牆花園 (Walled Garden) 網域。如果登入前的網絡使用未經過濾的解析程式，Portal 就會成為防護缺口。如果它在沒有冗餘的情況下 fail closed，訪客將完全無法登入。
服務失敗與阻擋看起來截然不同
被封鎖的網域應傳回封鎖頁面或明確的拒絕訊息。查詢失敗則會傳回逾時或 SERVFAIL。RFC 8914 擴充 DNS 錯誤增加了用來區分這些情況的代碼，例如 Blocked (15) 與 Filtered (17)，對比 No Reachable Authority (22)。請向您的服務台說明這兩者，以便他們能區分政策封鎖與服務中斷。
DNS 無法讀取域名以外的資訊
失敗封鎖能確保對每一次查詢做出政策決定，但並不代表能做到全方位覆蓋。直接連線至原始 IP 位址會完全繞過 DNS。在中斷前已經建立的連線則會繼續運作。DNS 也只能讀取網域，無法讀取完整路徑，這在為什麼 DNS 過濾無法看到完整 URL中有詳細說明。
若要了解這些限制在更廣泛的架構中位於何處，請參閱 DNS 過濾是否足夠？ 以及 DNS 過濾限制 概覽。
失敗封鎖 DNS 與 Purple Shield 有何關係？
Purple Shield 是適用於所有網路的防護型 DNS 與內容過濾。Shield 採用失敗封鎖機制，因此服務中斷絕不會讓網路失去過濾防護。每一次查詢都會獲得政策決定或完全不給予回應，絕不會出現未經檢查的結果。
您可以在任何 WiFi 網路獨立執行 Shield，或是配合 Purple Access 一起使用。您可以針對每個網路與每個 VLAN（虛擬區域網路，在共用硬體上記錄上的獨立網路）設定政策。單一場地的訪客、員工與後勤網路皆可各別套用不同的規則。Shield 不需要新增任何硬體，並能以雲端覆蓋層的形式運作於 Cisco Meraki、HPE Aruba、Ruckus、Juniper Mist、Ubiquiti UniFi、Cambium、Extreme Networks 與 Fortinet。
- ~241,000每週封鎖的威脅數St George's Healthcare NHS Trust
- 80,000+實體場地Purple 資料
- 90國家/地區Purple 資料
DNSFilter 與 Cisco Umbrella 同樣也在 DNS 解析階段進行過濾，因此部署位置的討論適用於這三者。您需要詢問各廠商的問題是備援機制位於何處。請詢問他們的漫遊代理程式在解析器無法連線時會如何運作，以及您可以設定多少個過濾位址。然後檢查您自己的 DHCP 與轉發器設定，確保沒有重新引入未過濾的路徑。
Shield 運作於 Purple 遍佈 90 個國家/地區、超過 80,000 個場地的全球網路中。請閱讀 Shield 如何運作 以了解部署細節。企業 WiFi 資安指南 則展示了 DNS 過濾如何與身分驗證及網路分割搭配使用。
這個概念發揮作用的時機是在變更維護期間，而非在產品手冊中。防火牆規則、DHCP 編輯或具備「彈性」的公用次要 DNS，決定了您的網路是否能維持過濾狀態。請在本季稽核這三項設定。接下來，請閱讀 DNS over TLS 與過濾：連接埠 853 帶來的改變，因為故障關閉 (fail-closed) 解析程式僅能保護實際使用它的裝置。
常見問題
故障關閉 DNS 是否意味著服務中斷會導致我的 WiFi 離線？
不會，當過濾器在備援解析程式上執行時就不會發生。只有在所有過濾解析程式同時無法存取時，故障關閉才會停止新的查詢。裝置會先對下一個過濾位址重試。快取的答案可在短暫中斷期間，繼續解析近期造訪的網站。請在上線前設計好備援機制，然後透過測試用 VLAN 一次封鎖一個解析程式來進行測試。
Shield 是否能搭配我現有的基地台與防火牆運作？
可以。Shield 在 DNS 解析層級進行過濾，因此不需要新硬體，並且能在任何 WiFi 網路獨立執行。Purple 可搭配 Cisco Meraki、HPE Aruba、Ruckus、Juniper Mist、Ubiquiti UniFi、Cambium、Extreme 和 Fortinet 運作。您只需將每個網路或 VLAN 的 DNS 指向 Shield，移除任何未過濾的後備位址，並套用個別網路的原則。產品頁面涵蓋了具體步驟。
Shield 如何計費？
Purple 會根據您的資產規模提供 Shield 報價，而非在此指南中公布標準價格。Shield 是一款安全性附加功能，您可以在任何 WiFi 網路上獨立執行，或與 Purple Access 一起搭配使用。因此，報價會反映您的網路與場所數量，而非新硬體。請提供您的場所數量、網路與 VLAN 數量，以及您是否已在使用 Purple，以索取報價。
如何從 DNSFilter 或 Cisco Umbrella 轉移，且過濾防護不中斷？
請一次切換一個網路或 VLAN。將測試用 VLAN 的 DHCP DNS 指向 Shield，確認封鎖與記錄，接著在變更維護期間轉移正式運作的網路。請完全移除舊的解析程式位址，而非將其留作次要 DNS。同時也請檢查員工裝置上的漫遊代理程式 (roaming agents)，因為它們的後備設定位於您的 DHCP 範圍之外。
是否有任何法規要求使用故障關閉 DNS 過濾？
沒有法規直接點名故障關閉 DNS，但控制框架期望安全控制措施能夠在可知的安全狀態下發生失效 (fail in a known, secure state)。NIST SP 800-53 Rev. 5 控制項 SC-24 涵蓋在可知狀態下發生失效。SC-7(18) 則涵蓋維持安全失效狀態的邊界保護。故障關閉過濾能為您提供每分每秒皆套用原則的證據，這有助於因應稽核人員或安全防護負責人的詢問。
如何測試我目前的過濾器失效行為？
從單一測試用 VLAN 封鎖前往您過濾解析程式的出站 DNS，並觀察裝置的反應。如果網站仍可載入且過濾器未記錄任何內容，則表示該網路為故障開啟 (fail-open)。請檢查 DHCP DNS 欄位、轉發器上游清單，以及任何硬編碼的裝置設定。一次封鎖一個過濾解析程式並重複測試，以確認備援機制正常運作。
單靠 DNS 過濾就足夠了嗎？還是需要安全 Web 閘道器？
DNS 過濾能涵蓋大多數訪客與場地網路威脅防禦與內容策略，但無法提供完整的 URL 檢查或資料遺失防護 (DLP)。它只能辨識網域名稱，無法查看路徑或檔案內容。若您需要這些控制功能，請在受管裝置上新增安全 Web 閘道器。請參閱 DNS 過濾與安全 Web 閘道器比較 瞭解兩者的界線。
Key terms
- 保護性 DNS
- 一種遞迴解析器，可在回應前根據威脅情報與內容策略檢查每個被查詢的網域，並回傳真實位址、阻擋頁面位址或拒絕。它會在任何工作階段開啟之前，針對 RFC 1035 所定義的名稱尋找採取行動。 英國 NCSC 依據此原則為公共部門營運保護性 DNS 服務。這是一項控制措施，而本決定即是管理其失效模式。
- 故障開放
- 一種架構設計，當過濾解析器無法連線時，DNS 查詢會退回至未套用任何策略的解析器。解析會繼續進行，但威脅阻擋、內容規則和記錄將停止運作。 您通常會在 DHCP 次要欄位或轉發器上游清單中將其視為公共或 ISP 解析器。它經常是在變更過程中意外導入。
- 故障關閉
- 一種架構設計，設備或轉發器可使用的每個 DNS 位址都指向具有相同策略的過濾解析器。僅當所有過濾解析器都無法連線時，尋找才會因超時或 SERVFAIL 而失敗。 只要後端有備援過濾解析器支援，這就是大多數訪客與員工 WiFi 的正確預設值。
- 故障安全 (NIST SC-7(18))
- NIST SP 800-53 Rev. 5 邊界保護增強功能 SC-7(18)，要求邊界設備在發生故障時避免進入不安全狀態。 審計人員可能會要求您提供相關證明。故障關閉 DNS 過濾能達到相同的實際效果。
- 在已知狀態下故障 (NIST SC-24)
- NIST SP 800-53 Rev. 5 控制措施 SC-24，要求系統在已知且確定的狀態下發生故障，而非在不可預測的狀態下故障。 沒有法規直接指名故障關閉 DNS，但在向審計人員或安全主管說明合理性時，此控制措施就是您可引用之框架語言。
- Serve-stale (提供過期快取數據)
- RFC 8767 行為，允許解析器在無法連線至上游伺服器時從過期快取進行回應，保持近期已解析名稱的正常運作。 它可以緩和短暫的停機，但它會重放上一次的決定，因此在此之後轉變為惡意的網域將不會被擷取到。
- SERVFAIL
- RFC 1035 中定義的 DNS 訊息格式伺服器失敗回應碼，當解析器無法完成查詢時傳回。 在失敗關閉（fail closed）的網路中，當每個過濾解析器都停止運作時，裝置就會收到此訊息。您的服務台必須將其與封鎖區分開來。
- 擴充 DNS 錯誤
- RFC 8914 代碼，為 DNS 回應添加詳細資訊，包括已被封鎖 (15)、已過濾 (17) 和無可達權威伺服器 (22)。 在診斷網站無法載入的報告時，它們能讓支援人員和工具區分政策封鎖與網路中斷。
- TTL (快取生存時間)
- RFC 1035 中定義的各個 DNS 資源記錄欄位，指定裝置或解析器可快取答案的秒數。 在短暫的中斷期間，快取的名稱繼續有效，而新名稱則失敗。訪客會將此情況回報為部分網站正常，部分網站無法存取。
- DNS 轉發器
- 防火牆、閘道或內部伺服器上的 DNS 服務，負責接收裝置查詢並將其轉發至已設定的上游解析器清單。 備援機制部位於其上游清單中。即使 DHCP 設定無誤，位於該處的公共解析器也會失敗開啟（fail open），包括員工網路中內部 DNS 後方的層級。
- DoH 和 DoT
- RFC 8484 中指定的 DNS over HTTPS，以及 RFC 7858 中指定的 DNS over TLS。兩者皆會將 DNS 加密傳輸至指定的解析器，並可繞過網路解析器。 這些屬於旁路行為，而非故障。失敗關閉（fail closed）設定對它們不起作用，因此您需要透過出口規則進行控制。
- 強制入口
- 訪客上網前看到的歡迎頁面。裝置必須先解析入口網站與圍牆花園（walled garden）網域，才能進行身分驗證。 未經過濾的登入前解析器會使入口網站成為漏洞。沒有備援機制的失敗關閉（fail closed）入口網站網路會導致訪客無法登入。
- 預設拒絕
- 針對過濾器尚未分類網域的過濾政策。它適用於過濾器正常運作時，並不屬於故障模式。 這經常與失敗關閉（fail closed）混淆。您可以在寬鬆政策下執行失敗關閉，或在嚴格政策下執行失敗開啟（fail open）。
Worked examples
外包商將公共解析器新增至訪客網路的 DHCP 作用域作為次要 DNS 以提高彈性。過濾解析器仍保持為主要 DNS。網路是否仍受到保護？
否。在次要欄位中放置公共解析器會使設計變成故障開放。當第一個伺服器回應緩慢時，某些作業系統就會查詢第二個伺服器，因此未過濾的尋找可能會每天洩漏，而不僅是在停機期間。若要確認，請從單一測試 VLAN 阻擋發往過濾解析器的出站 DNS。如果網站仍可載入且過濾器未記錄任何內容，則網路屬於故障開放。請將公共位址替換為帶有相同策略的第二個過濾解析器。然後檢查轉發器上游清單和硬編碼設備設定是否存在相同的瑕疵。最後，一次阻擋一個過濾解析器，以證明備援功能正常運作。
您正在將訪客與員工網路從 DNSFilter 或 Cisco Umbrella 轉移至 Purple Shield。如何在切換期間避免過濾出現空窗期？
請一次切換一個網路或 VLAN。首先將測試 VLAN 的 DHCP DNS 指向 Shield，然後確認阻擋與記錄皆如預期顯示。測試通過後，請在變更窗口期內轉移上線網路。請完全移除舊的解析器位址，而不是將其保留為次要 DNS。殘留的次要 DNS 會重新引入未過濾或不一致的路徑。同時也請檢查員工設備上的漫遊代理程式，因為它們的備援設定位於您的 DHCP 作用域之外。這種方法可確保在整個轉移過程中，每一次尋找都受控於策略決定。一旦移除舊廠商，也能保持 Shield 的故障關閉行為完好無損。
Frequently asked questions
失敗關閉（fail closed）DNS 是否意味著網路中斷會導致我的 WiFi 離線？
不會，當過濾器在備援解析器上執行時則不會。只有當所有過濾解析器同時無法連線時，失敗關閉（fail closed）才會停止新的查詢。裝置會先針對下一個過濾位址進行重試。快取的答案可在短暫中斷期間保持最近存取過的網站正常解析。在上線前請先設計好備援機制，然後透過從測試 VLAN 一次封鎖一個解析器來進行測試。
Shield 是否適用於我現有的基地台和防火牆？
是的。Shield 會在 DNS 解析階段進行過濾，因此不需要新硬體，並且能在任何 WiFi 網路獨立執行。Purple 可搭配 Cisco Meraki、HPE Aruba、Ruckus、Juniper Mist、Ubiquiti UniFi、Cambium、Extreme 和 Fortinet 使用。您只需要將每個網路或 VLAN 的 DNS 指向 Shield，移除任何未過濾的備援，並為每個網路套用政策即可。產品頁面涵蓋了具體步驟。
Shield 如何計價？
Purple 會針對您的物業環境提供 Shield 報價，而不是在本指南中公開標準價格。Shield 是一款安全性附加功能，您可以獨立在任何 WiFi 網路運行，或與 Purple Access 搭配使用。因此，報價會反映您的網路和場地狀況，而不是新的硬體設備。請提供您的場地數量、網路與 VLAN 數量，以及您是否已在使用 Purple，藉此索取報價。
如何在不中斷過濾的情況下從 DNSFilter 或 Cisco Umbrella 移轉？
請一次切換一個網路或 VLAN。將測試用 VLAN 的 DHCP DNS 指向 Shield，確認封鎖與紀錄功能無誤後，再於變更維護時間內切換上線的網路。請完全刪除舊有的解析器位址，而不是將其保留為次要 DNS。同時請檢查員工裝置上的漫遊代理程式，因為它們的備援設定位於您的 DHCP 範圍之外。
是否有任何法規要求採用故障封閉 (Fail Closed) DNS 過濾？
雖然沒有法規明確點名故障封閉 (Fail Closed) 的 DNS，但控制架構期望安全性控制措施能在已知的安全狀態下發生故障。NIST SP 800-53 Rev. 5 控制項 SC-24 涵蓋了在已知狀態下發生故障規範。SC-7(18) 則涵蓋故障安全 (Fail Secure) 的邊界防護。故障封閉過濾可提供每分鐘皆已套用原則的證明，這有助於因應查核人員或安全防護負責人的詢問。
如何測試我目前的過濾器故障行為？
從單一測試用 VLAN 封鎖對過濾解析器的外聯 DNS，並觀察裝置的反應。如果網站仍可正常載入且過濾器未記錄任何內容，則表示網路為故障開放 (Fail Open)。請檢查 DHCP DNS 欄位、轉發器上游清單以及任何寫死的裝置設定。每次封鎖一個過濾解析器並重複測試，以確認備援機制運作正常。
單靠 DNS 過濾就足夠了嗎？還是我需要安全 Web 網關？
DNS 過濾涵蓋了大多數訪客與場地網路的威脅防禦和內容原則，但不包含完整的 URL 檢查或資料遺失防護 (DLP)。它只能辨識網域名稱，無法辨識路徑或檔案內容。如果您需要這些控制措施，請在受控裝置上建置安全 Web 網關。請參閱 [DNS過濾 vs 安全 Web 網關](guide:dns-filtering-vs-secure-web-gateway) 了解兩者之間的界線。