web-dev-qa-db-ja.com

RFC 7505(Null MX)が必要なのはなぜですか?

IETF RFC 7505 は、メールを明示的に受信してはならないドメイン/ホストのMXレコードを記述します。これは、MXをドメインネームシステムのルートにポイントすることで実現されます。例えば、

nomail.example.com. 86400 IN MX 0 "."

なぜこれが必要なのですか?私の理解では、TLD invalidのドメインを使用することで、明示的な異議を唱えることができます。例えば、

nomail.example.com. 86400 IN MX 0 "spam.invalid."
nomail.example.com. 86400 IN MX 10 "null.invalid."

RFC 2782、DNS SRVも同様に「Aのターゲット」を指定していることがわかります。このドメインではサービスが明らかに利用できないことを意味します。」だから私は私の質問があると思います:

invalidがすでにこの機能を提供しているのに、DNSルートを使用して「利用不可」を意味する必要があるのはなぜですか?

18
Alpha Whiskey

それはあなたが.invalidを使用することになっているものではないためです。 .exampleと同様に、ローカルでのテストとドキュメント化を目的としています。

さらに、.invalidを使用すると、さらに別のことが起こります。追加のDNSルックアップとメールサーバーでのキューイングにより、頭の中で1回だけ再試行されます。

"."形式を使用すると、すぐにハードフェイルが発生するはずです。 MTAが直ちに配信を停止するようにします。少なくとも、RFCの紹介ではこれを読んでいます。

21
Zypher

全体としての質問は、RFC7505が有用なものを追加する理由を回答するためにすべて考慮する必要があるいくつかの異なる側面に触れています。


まず、RFC7505より前のメール配信方法の定義では、アドレスレコードを持つ名前に対してメール配信を試行しないことを明確に示す方法がありません。

RFC7505セクション1 から:

SMTPクライアントには、ドメインの電子メールを受け入れるサーバーを識別するための所定のシーケンスがあります。 [RFC5321]のセクション5では、これについて詳しく説明しています。基本的に、SMTPクライアントは最初にDNS MX RRを検索し、それが見つからない場合は、フォールバックしてDNS AまたはAAAA RRを検索します。したがって、これはDNSレコード(プライマリミッションが異なる)に電子メールサービスセマンティックスをオーバーロードします。

ドメインにMXレコードがない場合、送信者はドメインのAまたはAAAAレコードのアドレスにあるホストにメールを配信しようとします。 A/AAAAアドレスにSMTPリスナーがない場合、送信メール転送エージェント(MTA)が中止する前に、メッセージの配信が長期間(通常は1週間)繰り返し試行されます。これにより、メールが誤って送信された場合に送信者への通知が遅れ、送信者のリソースが消費されます。

このドキュメントでは、ドメインへのすべてのメール配信の試行を即座に失敗させるnull MXを定義しています。ドメインが配信試行の防止に専用のSMTPリスナーを作成する必要はありません。


次に、RFC7505がこれをどのように実装するかという問題があります(IN MX 0 .)。

RFC7505セクション から:

  1. Null MXを指定するMXリソースレコード

    ドメインが電子メールを受け入れないことを示すために、マスターファイルに "として書き込まれた、優先番号0と長さ0のラベルで構成されるRDATAセクションを持つ単一のMX RR([RFC1035]のセクション3.3.9を参照)をアドバタイズします。 "、交換ドメインとして、ドメインのメールエクスチェンジャーが存在しないことを示します。 「。」以来は有効なホスト名ではありません。ヌルのMXレコードを通常のMXレコードと混同することはできません。 の用法 "。"使用可能なサービスがないことを意味する疑似ホスト名として、SRV RR [ RFC2782 ]でモデル化されます。この場合、同様の意味があります。

    Null MXをアドバタイズするドメインは、他のMX RRをアドバタイズしてはいけません。

(強調を追加)

ここで述べたように、「null MX」の実装の詳細は、SRV RRタイプからすでに確立されているパターンに基づいています。 SRV RRタイプは多かれ少なかれMX RRタイプの一般化バージョンであるため、これを模倣することには意味があります。

したがって、 SRV RR type を定義するときに、本質的にすでに決定が行われています。


それでは、.invalidを活用してみませんか?

から RFC2606 section2

「.invalid」は、確実に無効であり、一目で無効であることが明らかなドメイン名のオンライン構築で使用することを目的としています。

ここでわかるように、この予約済みTLDは人間が使用するためのものです。ソフトウェアでこれの特別な処理を定義する前例はありません。

確かに、別の方法で実装された可能性もありますが、.を使用するという最小限のアプローチを選択しました。これは有効なホスト名ではないため、通常の使用を妨げることはありません。

9