區域傳輸在DNS伺服器之間複製區域資料或複製到授權的管理客戶端。 AXFR 是RFC 5936中所述的完整傳輸協定。意外可用的傳輸可能會顯示大量記錄清單，但其存在本身並不會使電子郵件身份驗證通過或失敗。評估揭露的內容、是否有意進行轉讓以及哪些控制措施控制存取。
建立權限和許可
參考： RFC 5936 §5.
確定確切的區域及其權威伺服器。在針對生產服務測試傳輸之前獲得授權。首先使用提供者支援的配置和審核工具（如果可用）。不要掃描不相關的域或嘗試繞過被拒絕的傳輸以使結果顯得更加引人注目。
合法的輔助伺服器可能需要傳輸存取權限。公共權威DNS服務和整個區域的轉讓許可是單獨的決定。檢查允許的客戶端、身份驗證機制、傳輸控制和操作目的。僅基於位址的白名單不能與加密用戶端身份驗證互換。
正確解釋傳回的數據
參考： RFC 5936 §2.2, RFC 5936 §3.
AXFR 根據協議返回區域內容，包括開始和結束 SOA 幀。成功的回應可能會公開已經可以單獨查詢但無法方便枚舉的名稱。評估清單是否揭示了敏感的內部命名、廢棄的服務或操作依賴性。首先，公共DNS不應該用作秘密存儲。
不要將拒絕等同於完全安全的區域。個人記錄仍可查詢，並且可以透過證書、配置洩漏或其他來源取得清單。相反，故意公開轉移並不自動成為漏洞；評估組織的政策和實際風險。
將郵件影響與庫存暴露分開
參考： RFC 6376 §3.1, RFC 5936 §1.
轉移不修改 SPF 授權，更換 DKIM 鍵或更改 DMARC 政策。發現一個 選擇器 name 不會洩漏其私人簽署金鑰。公用DKIM鑰旨在由驗證者檢索。如果區域包含憑證或機密值，則這是一個單獨的資料處理事件，需要其自己的回應。
使用清單來檢查所有權和過時的依賴關係，而無需聲明枚舉證明了漏洞。懸空別名可能值得調查，但實際的可控性取決於目標服務和配置。不要僅為了加強報告而註冊或索取他人的資源。
安全地重現評估
檢查點包括一個離線傳輸形狀的夾具，帶有起始 SOA、 TXT標記和匹配的結束 SOA。本地檢查驗證其簡單的框架並將其標記為庫存證據，而不是身份驗證失敗。第二個裝置包含拒絕回應，並被標記為傳輸被拒絕，而不是區域安全。
運行提供的腳本來重現這些標籤。這不是完整的 AXFR 解析器或網路傳輸。對於授權的隔離實驗室，使用所選伺服器的官方文件配置主要和輔助，測試允許的客戶端和拒絕的客戶端，並保留實際回應和相關存取配置。完整的主要/次要實施和存取控制測試仍未執行；下面較窄的保留腳本環回交換是單獨的。
修復時要牢記連續性
參考： RFC 5936 §5, RFC 5936 §6.
如果存取超出策略，則透過支援的伺服器控制來限制傳輸，同時保留合法的輔助操作。檢查存取限制和身份驗證，而不是假設其中一個可以替代另一個。更改後，驗證拒絕未經授權的存取並繼續授權傳輸、區域新鮮度和權威可用性。
記錄所揭露的記錄範圍、目標客戶、確切的補救措施和測試限制。將電子郵件身分驗證結果分開：仍需要代表性訊息測試和有效記錄查詢來評估郵件行為。一份好的報告可以解決暴露問題，而不會將DNS管理觀察轉變為不受支援的郵件安全聲明。
保留歷史電報證據
以下描述了保留的 2026 年 11 月 7 日環回捕獲，已檢查但未作為本次審查的網路實驗重新運行。新的離線模型檢查單獨記錄。
保留的檢查點記錄針對其自己的最小環回伺服器的實際 DNS-over-TCP 查詢。允許的 example.test AXFR 傳回符合的 SOA 框架和 apex TXT策略v=spf1 -all ；對超出範圍的 other.test 區域的查詢傳回 REFUSED。單獨的 UDP TXT查詢會檢索相同的SPF策略。這命名了特定的依賴關係： SPF評估器需要信封域的選定TXT策略，而 AXFR 會公開更廣泛的清單而不對其進行更改。保留查詢和回應線路位元組、端點和 UTC 時間。伺服器故意使用簡單的區域白名單，而不是生產身份驗證或完整的 AXFR 實作。