MD (Mail Destination) レガシーDNSチェッカー
MD (Mail Destination) レコードは、初期のインターネットメールルーティングの廃止された基盤となる柱です。MDレコードを理解するには、最新のSMTPインフラストラクチャが標準化される前に、ネットワークエンジニアが最初にどのようにメールフローを構造化しようとしたかを調べる必要があります。1980年代初頭、DNSプロトコルはメールルーティングの責任を、MDレコードと、その相棒であるMF (Mail Forwarder) レコードという2つの独立した明確なレコードタイプに厳密に分割しようと試みました。
厳格な最終宛先
このレガシーな分割ルーティングアーキテクチャでは、MDレコードは、特定のドメインのメールを受信する責任がある絶対的で最終的なホストを定義する役割を担っていました。ユーザーが admin@example.com 宛てにメールを送信した場合、送信側サーバーは example.com ゾーンに特にMDレコードのDNSクエリを実行します。ペイロードは、そのユーザーの物理的な受信トレイが存在するマシンの正確な正規ホスト名を返します。送信側サーバーは、そのホスト名でAレコードルックアップを実行してIPアドレスを見つけ、ペイロードの配信を試みます。これは完全に1対1のマッピングシステムとして動作していました。
単一障害点 (Single Point of Failure)
MDレコードのアーキテクチャには致命的な運用の欠陥がありました。冗長性、優先ルーティング、またはフェイルオーバー (Failover) のメカニズムに関する概念が全くなかったのです。これは大規模な単一障害点 (Single Point of Failure) となりました。ドメインのMDレコードにリストされている特定のメインフレームがメンテナンスでオフラインになったり、ハードウェア障害が発生したり、ネットワーク接続が切断されたりすると、受信メールは即座に送信者にハードバウンス (Hard-bounce) されてしまいます。送信側サーバーにメールを保留したり、バックアップサーバーを試したりするように指示するネイティブメカニズムが、MDプロトコル内には存在しませんでした。インターネットのトラフィックが急増するにつれて、ネットワークの停止に適切に対処できないこの問題は、企業や学術通信にとって受け入れられないものになりました。
非推奨化 (Deprecation) とMXの革命
これらの重大なボトルネックを解決するために、インターネットエンジニアリングタスクフォース (IETF) はRFC 973を批准し、MDレコードとMFレコードの両方を公式かつ永久に非推奨 (Deprecated) にしました。彼らは両方のレガシーシステムの機能を最新の MX (Mail Exchanger) レコードに統合しました。MXレコードは、優先度整数の概念を導入することでメールアーキテクチャに革命をもたらしました。管理者は、回復力の高い単一のルーティング配列内で、プライマリの宛先とセカンダリのバックアップ転送サーバーを定義できるようになりました。MXプロトコルは送信側サーバーに対し、最初に最も番号の小さい優先度を試し、プライマリが応答しない場合はシームレスにバックアップサーバーにフェイルオーバーするように指示しました。現代のMail Transfer Agent (MTA) はMDペイロードを考慮したり解析したりすることはないため、現在MDレコードをクエリすることはネットワークの歴史分析としての役割に限定されています。