web-dev-qa-db-ja.com

他のTXTレコードを含むSPFのサイズ

SPF仕様 は次のように述べています。

特定のドメイン名の公開されたSPFレコードは、それに対するクエリの結果が512オクテットに収まるように十分に小さいままにする必要があります（SHOULD）。そうしないと、DNSプロトコルの制限を超える可能性があります。

…

TXT形式のクエリへの返信のサイズを計算する場合、ドメイン名で公開されている他のTXTレコードを考慮に入れる必要があります。

最近のDNS仕様では、より大きなUDP応答が許可されていることも指摘しています（SPF仕様ではTCPが機能している）にDNSに依存するべきではないことを示しているため、制限の理由ですが）本当に「SHOULD」をオーバーライドしているようです。

問題は、多くの組織が確認のために同じドメインに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などを実行すると、切り捨てが発生する可能性があります。）

私は6か月前からEdgeに対抗してきましたが、今度は512バイトをはるかに超える新しいベンダーの検証レコードを追加する必要があります。 SPFレコードを統合するためにできる限りのことを行い、既存の確認レコードを削除できないことを確認しました。

ここで何をしますか？検証レコードはありませんが、SPF仕様も無視したくありません。そうは言っても、マイクロソフトはそれを無視しているようで、メールが拒否されているとは思いません。

domain-name-systememailsmtpspf
2
wfaulk

SPF仕様を再度読んだ後のTXT RRsetサイズに関する懸念は、クライアント both がEDNSをサポートしていない場合、DNS応答が切り捨てられる可能性があることです and クライアントはDNS over TCPをサポートしていません。DNSover TCPは常にDNSの必須部分であり、警告は壊れたDNSに関係しているようです。（公平を期すために、TCP経由でDNSが特に過去に壊れていた場所がたくさんあります。）

しかし、私は自分のDNSサーバーがTCP経由でアクセスできることを知っており、他の人々のアクティブに壊れたDNSに（比較的）新しいDNS仕様をサポートしていることを確認するよりもずっと心配していません。

したがって、答えは、私が 「正当な理由…[アイテム]を無視する[そして]完全な影響を[理解した]慎重に検討した」 のであるようです。

0
wfaulk