2

dmarc.orgでは、DNS の IN TXT レコードをゾーン ファイル内の特別な形式で記述して、テキスト エディターの行からはみ出さないようにすることを提案しています。

一般的なコマンドライン ツールを使用して取得すると、DMARC ポリシー レコードは次のようになります。

% dig +short TXT _dmarc.example.com.
"v=DMARC1\; p=none\; rua=mailto:dmarc-feedback@example.com"

このようなレコードを公開するために、ドメイン所有者の DNS 管理者は、適切なゾーン ファイルに次のようなエントリを作成します (従来のゾーン ファイル形式に従います)。

; DMARC record for the domain example.com

_dmarc  IN TXT ( "v=DMARC1; p=none; "
                 "rua=mailto:dmarc-feedback@example.com" )

NSD を使用した実際のゾーン ファイルの例に従ってみました。ただし、次にドメインを照会すると、実際には複数の行にまとめられた結果も得られます。

% dig +short TXT _dmarc.example.su
"v=DMARC1\; " "p=reject\; " "rua=mailto:rua-dmarc@example.su"

これは期待されていますか？これらの TXT レコードを解析して DMARC / SPF / DKIM などを取得するはずのソフトウェアが壊れる可能性はありますか?

4

2 に答える 2

2

レコードの個々のコンポーネントは、ネットワーク上でフォーマットTXTで送信されるため、それぞれ最大 255 文字しか含めることができません。<length><data ...>

255 文字を超える可能性があるコードは、複数のコンポーネントを 1 つの文字配列に結合できる必要があります。

マスター ファイル形式では、文字列を囲む中かっこは、複数のコンポーネントが 1 つの TXT レコードに含まれることを示します。それらがないと、2 つの別個の TXT レコードが作成され、2 つのレコードの相対的な順序は定義されず、変更される可能性があります。

于 2015-03-27T22:43:24.753 に答える
0

DMARC チェッカーの最終的な実装に依存するため、判断するのは困難です。ただし、DMARC ドキュメントに詳細が記載されていても、DMARC レコードはエディタがオーバーフローするほど大きくはありません。

私の場合、Ubuntu Trusty (14.04) で最後のopendmarcパッケージを とともに使用するとPostfix、奇妙な/不正な形式の DMARC DNS レコードを処理するときにデーモンがクラッシュしました (ただし、あなたが言及した場合とは異なります)。

単純に 1 行のアプローチを追加して、安全にプレイします。これは、チェッカー ソフトウェアが破損する可能性があるためだけでなく、実際にはポリシーが調整されていないように見えるため、メールが拒否されることはさらに悪いことです!

したがって、次のようなものを追加します。

_dmarc.example.su    IN TXT "v=DMARC1; p=reject; rua=mailto:rua-dmarc@example.su"
于 2015-03-27T22:29:21.567 に答える