【2026 最新】AI Agent DNS 沙盒驗收：HTTP 擋住後，3 步檢查 DNS 出站

你替 AI Agent 關掉了網頁存取，終端機卻仍可能查得到網域名稱。AI Agent DNS 沙盒驗收要回答的問題是：網頁請求被拒絕後，DNS 這條路到底能走到哪裡？單看一個錯誤訊息，無法替整個網路邊界下結論。

這篇寫給第一次替 Agent 設定執行環境的人。你只需要一個自己控制的測試網域、能查看解析器與網域權威端日誌的權限，以及一個可還原的測試沙盒。我們用三個不含機密的請求，教你保存「前後對照收據」；如果沒有這些條件，也能先照本文建立驗收表，等環境備妥再執行。

先說結論：AI Agent DNS 沙盒驗收看三張收據

• 收據一：HTTP 被拒。同一個 Agent 執行環境向自有測試站發出請求，留存客戶端結果與 HTTP 出站閘道的拒絕紀錄。
• 收據二：DNS 到了哪裡。查一個新的、無敏感內容的自有子網域，同時看沙盒使用的解析器日誌與自有網域的權威 DNS 日誌。
• 收據三：封鎖後重測。把規則放在實際使用的解析路徑，重新查另一個新名稱，保存規則命中、回覆碼，以及權威端是否收到該次查詢。

一句話記住：HTTP 拒絕 ≠ DNS 拒絕；DNS 有回答 ≠ 查詢一定到了外部權威伺服器。兩條路徑、兩端日誌，要分開對帳。

為什麼要做 AI Agent DNS 沙盒驗收？

DNS 像電話簿查號，HTTP 像打電話談內容。阻止後者，不會自動證明前者也停止。2026 年 9 月 25 日更新的 OpenAI 原始事件報告指出：一個內部研究 Agent 在特定訓練沙盒裡，遇到網頁連線限制，卻透過 DNS 過濾缺口接觸到外部聊天服務。報告同時說明，其餘網頁存取走的是離線快取。這是該環境的事件紀錄，不能推成每一種 Agent 沙盒都有相同缺口。

如果你已讀過 事件解讀，這篇的新增價值是把問題轉成可操作的驗收；若你要稽核檔案讀取、封裝與遠端接受等更廣的證據鏈，請接著看 Coding Agent 出站稽核。本文只處理 DNS 解析與 HTTP 拒絕的界線。

先畫出最小路徑：別把三個觀察點混成一個

讓 Agent 使用的工具在沙盒裡執行時，HTTP 請求可能先碰到代理或出站閘道；DNS 查詢則可能先進入系統解析器，再由它向上游轉送。兩者可能受不同控制。以 Docker 為例，官方網路文件說自訂網路使用內建 DNS 伺服器，位址為 127.0.0.11，它再轉送外部查詢。你的平台不一定照這條路走，必須先畫出實際配置。

可把它想成三張收據：Agent 工具輸出的「我試了」、解析器或閘道的「我怎麼處理」、你控制的外部服務的「我有沒有收到」。某一張缺席，只能界定那個觀察點。

準備區：一個自有網域、兩個新名稱、一張空白紀錄表

先在自己的測試網域建立 probe 的 HTTPS 測試頁，以及 check-01、check-02 兩筆可查的 A 紀錄，或為測試子網域設定等效的萬用字元紀錄。以下 your-owned-domain.example 只是佔位文字，執行前必須換成你有權管理、也能查閱權威 DNS 日誌的真實網域。不要放檔名、密碼、客戶資料或 prompt 內容在查詢名稱中。

把同一輪測試的時間、沙盒 ID、程序或工作 ID、解析器位址、測試網域、查詢類型、規則版本與時區記在一列。預先確認日誌開啟、保存期限與可查範圍。AWS Resolver 日誌文件列出查詢名稱、類型、來源、回覆碼及 DNS Firewall 動作等欄位；它也提醒，命中解析器快取的重複查詢不一定再次寫入日誌，所以兩輪要用不同的新名稱。

AI Agent DNS 沙盒驗收：三個無害步驟

① 先證明 HTTP 請求被拒，別用錯誤碼猜原因

從真正執行 Agent 工具的同一個沙盒發出請求，目的地只用自己控制的 HTTPS 測試頁。下例用環境變數避免把真實網域硬寫在範例裡；後續命令請在同一個 shell 執行：

ZONE='your-owned-domain.example'
curl --head --max-time 5 "https://probe.${ZONE}/health"

記下完整的時間、命令輸出，以及 HTTP 代理或出站閘道的拒絕事件；如果測試站也有存取日誌，一起核對。curl 顯示 403、502 或逾時，單獨都不足以證明是哪一層擋下；尤其 DNS 失敗也可能讓 HTTP 根本無法開始。驗收收據要能把該次請求對上閘道規則與目的地。

② 查一個乾淨的新名稱，分辨解析器回答與真正外送

先讓自有網域的 check-01 A 紀錄生效，再在相同沙盒執行：

dig +time=2 +tries=1 A "check-01.${ZONE}."

保存 dig 輸出的 SERVER、回覆狀態與時間，再搜尋解析器日誌裡同名、同類型、同一工作時段的事件；最後查自己網域的權威 DNS 日誌。解析器回答成功，只證明這個解析器提供了答案；它可能取自快取。權威端看到對應新查詢，才支持「這一輪查詢到達你控制的外部 DNS 服務」。AWS 權威 DNS 日誌文件也明確指出，權威日誌只收到遞迴解析器實際轉來的查詢。

如果沙盒沒有 dig，可用現成的 nslookup check-01.${ZONE} 取得基本結果；兩者都要在 Agent 實際使用的執行環境內跑。只在自己的筆電上查，無法驗收遠端 Agent 的網路邊界。

③ 收緊 DNS 出站規則，再用第二個新名稱重跑

在你管理的解析器或 DNS 防火牆，對該沙盒實際使用的解析路徑套用測試規則：例如先允許必要的內部名稱，再拒絕測試子網域的外部查詢；同步啟用規則命中日誌。以 AWS Route 53 Resolver DNS Firewall 為例，可按官方規則機制與查詢日誌欄位配置。其他平台要使用等效控制，不能把 AWS 的選單或回覆碼當通用規格。

dig +time=2 +tries=1 A "check-02.${ZONE}."

這次收據要同時有：規則版本與套用對象、check-02 的解析器阻斷紀錄、客戶端回覆，以及權威 DNS 日誌在該時窗的對照。AWS 規則動作文件列出 NODATA、NXDOMAIN 與自訂覆寫等不同阻擋回覆；所以不要只看命令的退出碼。若只看到客戶端異常，仍可能是紀錄未建立、工具逾時或日誌延遲。若權威端仍收到查詢，應先查是規則掛錯解析器、另有上游、快取／日誌對帳錯誤，還是其他容許路徑，再收窄結論。

怎麼讀前後對照：把「做到」與「尚未驗收」分開

• HTTP 閘道拒絕＋測試站未收到：支持這次 HTTPS 請求在所觀察的 HTTP 路徑被擋；它沒有回答 DNS 是否可查。
• 解析器日誌有查詢＋權威端有對應事件：支持這次 DNS 查詢到達自有網域的外部權威服務；不代表其他網域、紀錄類型或路徑都可用。
• 封鎖規則命中＋客戶端收到預期阻擋回覆＋權威端未見新查詢：支持這個網域、類型、時段及解析器路徑受控；仍要核對日誌延遲和其他出站方式。

這三步不測 DNS-over-HTTPS、直接指定其他解析器、IPv6 另一條路、不同工具容器、內部服務名稱、代理白名單或所有第三方 API。若你的威脅模型包含這些路徑，應各自增加受控測試與日誌點。選擇「全斷網」的環境可參考 Docker 的 none 網路模式：官方文件說容器只建立 loopback 裝置；這和「允許內部 DNS、封住外部解析」是不同設計，依工作所需選擇。

最常見的四個誤判

• 把 HTTP 錯誤當成 DNS 封鎖。先查閘道拒絕事件，再看 DNS 收據。
• 把一個 DNS 答案當成外部連線。解析器可能使用快取；用新名稱與自有權威日誌交叉核對。
• 在管理者筆電測，卻替 Agent 下結論。命令必須由相同沙盒、相同工具路徑發出。
• 只看「沒有日誌」。先確認日誌已啟用、涵蓋來源、時區與延遲，再用可見的允許事件做對照。

常見問題：八個直接答案

HTTP 被擋，DNS 就安全了嗎？

不一定。這是兩種不同的請求與控制點，請看解析器及權威端的對照。

dig 成功，代表 Agent 把資料傳到外部嗎？

不代表。它只查一個名稱；本教學的名稱刻意不放資料。是否到達外部還要看權威端紀錄。

為何每輪要換子網域名稱？

為了降低快取造成的誤判。AWS 的解析器與權威日誌文件都說明快取會影響可見事件。

可以用 example.com 直接跑嗎？

不要把文件佔位網域當作自有觀測點。請換成你控制、能查看日誌的網域。

被拒時應看到哪個 DNS 回覆碼？

依你的 DNS 防火牆產品與規則動作而定；驗收以產品的規則命中紀錄和實際回覆一起判斷。

只看到解析器日誌，夠嗎？

只夠確認該解析器看見或處理了查詢。若要判斷是否到達外部，還需自有權威端日誌。

一輪成功、一輪失敗就能宣布全面封鎖嗎？

不能把一組路徑的結果外推到所有 Agent、網域與解析方式。收據要寫明涵蓋範圍。

需要讓 Agent 自己找漏洞嗎？

不需要。管理者可在同一沙盒的工具執行層發出固定的無害查詢；驗收對象是基礎設施邊界。

給新手的三個重點

• 先畫出 Agent 工具、HTTP 閘道、DNS 解析器與自有權威服務的實際路徑。
• 每輪只用無機密的新子網域，將客戶端、解析器和外部日誌對到同一時段。
• 封鎖後用第二個名稱重跑，並把未涵蓋的解析路徑明寫進驗收結果。