☰

SPF 與其他 TXT 記錄的大小

tag-icon • tag-icon domain-name-system email smtp spf
SPF 與其他 TXT 記錄的大小

這SPF規格說：

給定網域的已發布 SPF 記錄應保持足夠小，以便查詢結果能容納在 512 個八位元組內。否則，可能會超出 DNS 協定限制。

……

請注意，在計算 TXT 格式查詢的回覆大小時，必須考慮在網域上發布的任何其他 TXT 記錄。

它還指出，更新的 DNS 規範允許更大的 UDP 回應（限制的原因，因為 SPF 規範意味著您不應該依賴 TCP 上的 DNS 工作），但這似乎並沒有真正覆蓋「應該」 。

問題在於，許多組織都需要同一網域上的 TXT 記錄用於驗證目的（例如facebook-domain-verification、google-site-verification、atlassian-domain-verification、adobe-sign-verification等），並且可以快速將總 TXT RRset 的大小遠遠超過 512 位元組。

看起來大多數大型組織都遵守這項規定，但也有一些組織超出了規定：

% dig +noall +stats netflix.com TXT | grep 'MSG SIZE'
;; MSG SIZE  rcvd: 593

% dig +noall +stats linkedin.com TXT | grep 'MSG SIZE'
;; MSG SIZE  rcvd: 632

% dig +noall +stats twitter.com TXT | grep 'MSG SIZE'
;; MSG SIZE  rcvd: 642

% dig +noall +stats microsoft.com TXT | grep 'MSG SIZE'
;; MSG SIZE  rcvd: 1459

（您可以透過執行類似的命令來看到潛在的截斷發生dig +notcp +noedns +ignore microsoft.com TXT。）

我已經在邊緣掙扎了六個月，現在我需要為新供應商添加另一個驗證記錄，這將使我遠遠超過 512 位元組。我已盡我所能來鞏固我的 SPF 記錄，並且我已確保無法刪除現有的驗證記錄。

我應該在這裡做什麼？我不能沒有驗證記錄，但我也不想忽略 SPF 規範。也就是說，微軟似乎忽略了這一點，我不認為他們的郵件會被拒絕。

答案1

重新閱讀 SPF 規格後，對 TXT RRset 大小的擔憂是，如果客戶端兩個都不支援EDNS和客戶端不支援 TCP 上的 DNS。 TCP 上的 DNS 一直是 DNS 的必要部分，但需要注意的是 DNS 損壞。 （公平地說，TCP 上的 DNS 在很多地方都被破壞了，尤其是在過去。）

但我知道我的 DNS 伺服器可以透過 TCP 訪問，而且我更關心的是確保他們支援（相對）新的 DNS 規範，而不是其他人主動破壞的 DNS。

所以答案似乎是我有“有充分的理由……忽略[該]項目，[並且]其全部含義[已]被理解並仔細權衡”。

相關內容