SPF 與其他 TXT 記錄的大小

SPF 規範說：

給定域名的已發布 SPF 記錄應保持足夠小，以使其查詢結果適合 512 個八位字節。否則，可能會超出 DNS 協議限制。

…

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

它還指出，最近的 DNS 規範允許更大的 UDP 響應（限制的原因，因為 SPF 規範暗示您不應該依賴 DNS over TCP 工作），但這似乎並沒有真正覆蓋“應該” .

問題在於，許多組織需要同一域中的 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 規範。也就是說，微軟似乎忽略了它，我不認為他們的郵件被拒絕了。

重讀 SPF 規範後，對 TXT RRset 大小的擔憂是，如果客戶端既不支持 EDNS，又不支持基於 TCP 的 DNS，DNS 響應可能會被截斷。基於 TCP 的 DNS 一直是 DNS 的必需部分，並且警告似乎與損壞的 DNS 有關。（公平地說，有很多地方 DNS over TCP 被破壞了，尤其是在過去。）

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

所以答案似乎是我有“正當理由……可以忽略$$ the $$物品，$$ and $$全部含義$$ have been $$理解並仔細權衡”。

引用自：https://serverfault.com/questions/1000170