Check-Host.cc

MF (Mail Forwarder) レコードは、インターネットメールルーティングの初期段階でMD (Mail Destination) レコードと連携して動作していた絶滅したDNSレコードタイプです。MDレコードが最終的な受信トレイの宛先を厳密に指していたのに対し、MFレコードは1980年代のインターネットバックボーンの巨大な信頼性の問題を解決するために設計されました。これは、ドメインに代わって受信メールを受け入れ、それを保持し、経路が利用可能になったときに最終的な宛先に向けて積極的に転送する中間ホスト (ネットワークリレー) を定義するように設計されていました。

Store-and-Forward ネットワークアーキテクチャ

初期のネットワークトポロジにおいて、継続的で24時間365日のTCP/IP接続は信じられないほどまれでした。多くの学術機関や企業のメインフレームは、ダイヤルアップリンクや断続的なARPANETブリッジを介して広範なネットワークに接続していました。MFレコードは、これらの「ストアアンドフォワード」環境にとって絶対に不可欠でした。ドメインのプライマリ宛先サーバーが1日12時間オフラインになることがわかっていた場合、管理者は提携機関の高可用性で常時接続されているサーバーを指すMFレコードを設定できました。送信側サーバーはDNSに問い合わせてMDに到達できないことを認識し、ペイロードをMFホストにルーティングします。転送サーバーはローカルディスクにメールをスプール (Spool) しておき、最終宛先サーバーがネットワーク接続を再確立したときに自動的に一括 (Bulk) で転送していました。

分割ゾーン (Split Zones) の複雑さ

概念的にはしっかりしていましたが、最終目的地 (MD) と中間リレー (MF) に対して別々の異なるDNSレコードを維持することは、ネットワーク管理者にとって複雑すぎ、非常にエラーが発生しやすいことが証明されました。DNSゾーンの管理にはフラットテキストファイルの細心の注意を払った手動編集が必要であり、フォワーダーのマッピングを宛先のマッピングと同期させておくことで、ルーティングループやペイロードのドロップが頻繁に発生しました。さらに、優先順位ランキングシステムがなかったため、管理者は複数層のバックアップ転送サーバーを簡単に構成できませんでした。

MXレコードへの統合

硬直したMFアーキテクチャは、はるかに動的なMX (Mail Exchanger) レコードを導入したRFC 973の公開後に完全に放棄されました。MXプロトコルはMFレコードの機能を完全に吸収しました。特定のホストにより高い優先度番号 (接続優先順位が低いことと等しい) を単に割り当てるだけで、現代の管理者は、あらゆる標準のMXレコードを事実上のメールフォワーダーまたはスプーリングリレーに即座に変えることができます。プライマリサーバーの優先度は10になり、バックアップスプーリングサーバーの優先度は50になります。この統一されたアプローチにより、専用のMFレコードは永久に時代遅れになり、最新のDNS解析ソフトウェアはMFクエリを完全にドロップします。