[ DNS和網域 ]

使用 dig 檢查身份驗證記錄和委託

使用明確挖掘查詢來比較身份驗證記錄、伺服器回應和委派。保留證據,不要將查找成功與郵件成功混淆。

由EmailAuth研究團隊提供 · 6 分鐘閱讀

[ 重點 ]

  • 使用寄件者證據選擇SPF域或DKIM選擇器。
  • 在縮短輸出之前固定工具範圍並保留完整響應。
  • 在解釋非遞歸比較之前驗證權威。
  • 保持追蹤、傳輸和DNSSEC聲明比端到端驗證更窄。
在此頁面上

將尋找變成精確的問題

使用 dig 向指定DNS伺服器詢問確切的擁有者和記錄類型,然後保留足夠的上下文來解釋回應。對於電子郵件身份驗證,核心問題很少是網域是否有任何 TXT記錄。它是發送者或驗證者所使用的依賴關係是否存在於正確的名稱處,並且可以透過相關路徑來解析。

本指南中的範例針對 ISC BIND 9.20.13 dig 所記錄的語法。這是一個固定的文件範圍,而不是聲稱每個已安裝的挖掘都有該版本或它是最新版本。所有指令均建議只讀DNS查詢或本機版本檢查。這裡沒有人被處死。 example.com名稱和192.0.2.0/24位址是文件佔位符,而不是有效的解析器設定。

從電子郵件實際使用的身份開始

為了 SPF,識別相關SMTP身分中使用的網域,而不是自動使用可見的 From 域。為了 DKIM,取得簽章域並 選擇器 從訊息的簽名。鍵查找擁有者結合了選擇器, _domainkey 和簽章域。不要從供應商的名稱中猜測選擇器。 RFC 7208 RFC 6376

尋找 _dmarc.example.com. 可以檢查該所有者的保單記錄。它本身並不是策略發現的完整實現,也不是 結盟 評估。將結果交給郵件專家時,保留訊息身分和適用的策略發現上下文。 DNS可見性和身份驗證結果屬於相關但獨立的證據欄位。 RFC 9989

寫一份問題表,其中包含所有者、類型、查詢原因和預期權限。這個小準備工作可以防止針對錯誤領域的看起來有吸引力的答案被接受為修復方案。尾隨句點使範例的名稱明確的絕對DNS名稱。

使初始查詢可重現

建議的本地命令 挖掘-v 記錄工具版本。對於受控查詢形狀,請使用 dig -r @ 192.0.2.53 _dmarc.example.com 。 TXT。這 -r 選項避免了每個使用者的 dig 預設值,而伺服器參數標識了DNS伺服器。僅替換兩個佔位符以進行單獨授權的查找。在製作緊湊摘錄之前保留完整的輸出。 ISC挖掘手冊

記錄結果中實際報告的 UTC 時間、來源網路上下文和伺服器。避免以隱藏除答案之外的所有內容的命令開始。稍后仅显示简短的答案视图可能会很方便,但最初的证据应保留问题、状态、标志、答案和权限部分,以及与传输相关的消息。這些細節區分了缺席、轉介和失敗。

建議的配套問題是 dig -r @ 192.0.2.53 example.com 。 TXT 和 dig -r @ 192.0.2.53 selector1._domainkey.example.com 。 TXT。這些是語法範例,並未聲明任一名稱都具有身份驗證記錄。從已核准的調查中選擇實際名稱,並且永遠不要將 ANY 查詢視為區域中所有內容的保證清單。

比較遞歸觀察和​​權威觀察

首先確定您查詢的是哪個伺服器。遞歸解析器可以傳回快取的資料;權威伺服器對其服務的區域進行應答。為了與單獨驗證的權威機構進行比較,建議的表格是 dig -r @ 192.0.2.54 _dmarc.example.com 。 TXT +norecurse。禁用遞歸不會使任意伺服器具有權威性。檢查回應和委託證據,而不是僅僅信任所選的 IP 位址。 RFC 1034

如果遞歸結果和權威結果不一致,則兩者都保留。在指責傳播之前比較名稱、類型、值、回應狀態和時間戳記。減少快取的 TTL 可以提供信息,但並不是每個觀察者的通用到期期限。負快取條目也遵循其自己的規則。 RFC 2308

從結構上閱讀答案。多個帶引號的字串可以屬於一個TXT資源記錄;多個TXT資源記錄是不同的情況。不要將兩種形式展平為一個以空格分隔的字串。在郵件專家評估SPF或DKIM語法之前保留記錄邊界。一個 CNAME 引入另一個名稱來進行調查,而不是證明最終密鑰或策略文字可用。 RFC 1035

僅當出現問題時才跟踪委託

建議的查詢 dig -r +trace example.com 。 NS 遵循來自根的引用。它發送多個網路查詢,因此相應地批准診斷範圍。新增伺服器參數不會將整個追蹤限制在該解析器中。追蹤調查來自運營商網路的委託;它不會重現遠端電子郵件接收者所做的每一個決定。 ISC挖掘手冊

查看追蹤時,請確定上次成功引用、聯絡的伺服器以及解析停止的位置。某一階段逾時則不允許編輯 名稱伺服器。將調查結果與註冊商和DNS所有者的清單進行比較,然後將下一次調查分配給適當的所有者。避免將一條不完整的追蹤變成遷移建議。

縮小失敗和驗證聲明的範圍

NXDOMAIN是沒有請求資料的成功回應,而SERVFAIL需要不同的後續步驟。不要將所有三個都轉換為遺失的身份驗證記錄。如果懷疑運輸,建議 +TCP 比較可以幫助分離路徑,但一次傳輸的成功並不能證明每個接收者都可以解析記錄。 RFC 1035 RFC 7766

挖掘 +dnssec 選項請求 DNSSEC 材料;它的存在不是一個獨立的密碼驗證結果。將驗證結論與適當的解析器行為和可信證據連結。透過簡要說明哪個伺服器回答了哪個問題、何時以及哪些仍不確定的內容來完成調查。本文所需的帶時間戳的權威和遞歸抄本仍然缺失;這些建議的命令不能取代它們。

[ 外帶 ]

將確切的所有者、類型、伺服器和完整回應放在一起。沒有上下文的命令和螢幕截圖無法建立身份驗證結果。

[ 按角色 ]

這對您意味著什麼

選擇您的角色以執行後續實際步驟。

DNS工程師

保留伺服器和回應語義

工程師的工作是使每個結論都可以追溯到特定的問題和有利位置。簡短的摘錄應與其完整的基本回應保持聯繫。

後續步驟

  1. 記錄挖掘版本、伺服器、來源上下文和 UTC 時間。
  2. 在非遞歸比較之前驗證權威。
  3. 保持逾時、引用、 NODATA和SERVFAIL分支不同。

交付能力分析師

將查詢連接到訊息

技術上正確的查找可能涉及錯誤的身份。使用訊息證據來選擇依賴關係並將結論限制為DNS實際建立的內容。

後續步驟

  1. 提取相關SPF身份或DKIM域和選擇器。
  2. 共享結果時保留TXT記錄邊界。
  3. 在聲明身份驗證或交付成功之前需要接收者證據。

事件協調員

限制下一個診斷步驟

追蹤或傳輸差異可以證明進一步調查的合理性,而無需證明DNS編輯的合理性。將未解決的圖層分配給正確的所有者,並保持證據年代完整。

後續步驟

  1. 說明最後確認的成功問題或轉介。
  2. 確定下一個操作是查詢還是修改更改。
  3. 請求單獨授權的後續證據,而不是推斷的修復命令。

[ 常見問題解答 ]

常見問題

為什麼這些範例包含 dig -r?

在固定的 BIND 9.20.13 文件中,-r 阻止從 .digrc 讀取每個使用者的預設值。這提高了再現性,但沒有修復伺服器、網路或查詢身分。分別記錄這些。

我應該查詢哪個DKIM選擇器?

使用相關DKIM簽章或核准的寄件者配置中的選擇器和簽章域。一個網域可以有多個選擇器,猜測與供應商相關的名稱可以檢查錯誤的依賴關係。透過查詢保留身分來源。

+norecurse 會使答案具有權威性嗎?

不會。它會更改請求的遞歸設置,而不是伺服器的角色。從授權證據中確定預期的權限並檢查答案。不具有權威性的伺服器可能會傳回引用、快取資訊或失敗。

我應該使用 ANY 來收集所有身份驗證記錄嗎?

不要將其用作完整的庫存。詢問與郵件身分相關的類型和確切所有者,並在需要區域內容時使用授權提供者清單。寬泛的查詢並不能證明不存在其他選擇器或記錄。

兩個帶引號的字串與兩個TXT記錄相同嗎?

不可以。一條TXT記錄可以包含多個字串。在評估身份驗證資料之前,請保持該結構與同一所有者的多個資源記錄不同。展平的支撐萃取物可以掩蓋差異。

+trace 是否重現接收者的查找?

不。它遵循運營商網路的委託。其目的是檢查該路徑,而不是遠端接收者的快取、驗證策略或應用程式行為。保留它停止的地方,避免將一條痕跡視為普遍視圖。

請求DNSSEC記錄是否驗證網域?

不可以。 dig +dnssec 選項請求DNSSEC資料。驗證聲明需要適當的驗證過程和可靠的證據。不要僅僅因為查詢包含該選項就將答案標記為安全。

當UDP和TCP結果不同時該怎麼辦?

保留問題、目的地、時間戳記和完整答案。升級傳輸差異而不更改身份驗證記錄來進行補償。一條成功的路徑並不能證明每個接收者都可到達。這裡的例子還沒有被執行。

[ 來源 ]

來源

  1. ISC BIND 9.20.13 手冊頁:dig
  2. RFC 1034 :網域:概念與設施
  3. RFC 1035 :網域:實作與規範
  4. RFC 2308 : DNS查詢的負緩存
  5. RFC 6376 :網域金鑰識別郵件簽名
  6. RFC 7208 :用於授權在電子郵件中使用網域的寄件者策略框架
  7. RFC 7766 :透過 TCP 的DNS傳輸:實作要求
  8. RFC 9989 :基於網域的訊息驗證、報告和一致性

[ 詞彙表 ]

詞彙表

絕對所有者名稱
以根結尾的完全指定的DNS名稱,在這些範例中顯示為尾隨句點。
需要遞迴
請求伺服器尋求解析的DNS請求標誌;更改它不會更改伺服器的權限。
推薦
DNS回應將解析定向到其他名稱伺服器,而不是提供最終請求的資料。
TXT字串
TXT記錄資料的一個組成部分;多個字串可以屬於一個TXT資源記錄。
診斷記錄
實際命令、執行上下文、觀察時間和完整輸出的保留記錄;提議的命令不是文字記錄。

企業出處

為什麼頂級金融機構和政府 退役了他們的電子郵件安全儀表板。

傳統的電子郵件驗證平台會向您出售儀表板並要求您的工程師來完成這項工作。在高風險環境中,手動監督意味著延遲執行、配置漂移和不受監控的影子域。

EmailAuth是代理電子郵件來源平台。 我們的代理人強制執行 p=reject,保持第三方寄件者一致並將您的網域移至完整狀態 RFC 9989 合規性、新的DMARC標準,以及人機互動審核能力。

政府 大型企業 一級金融機構

SaaS · 專用租賃 · 氣隙本地部署 · BYOK 加密

知識庫