MB (Mailbox Domain) レガシーレコード検索
MB (Mailbox) レコードは、元のRFC 1035 DNS仕様における興味深い実験的アーティファクトです。最新のネットワークアーキテクチャでは、ドメインネームシステムは物理サーバーまたはIPアドレスへのトラフィックのルーティングを厳密に処理し、内部アプリケーション (電子メールサーバーなど) はペイロードを解析してデータがどの特定のユーザーに属しているかを把握します。MBレコードはこれらの境界線を曖昧にしようとしました。組織のメールをMXレコードを介して中央サーバークラスターにルーティングする代わりに、MBレコードは、個々のユーザーのメールボックスをDNSゾーンファイル内でネイティブに特定のホスト名に直接マッピングしようとしました。
Direct-to-Host のメールルーティング
MBプロトコルの理論の下では、DNS層はネットワーク内のすべての従業員またはユーザーに関する詳細な知識を持っていることになります。たとえば、管理者は理論的にMBレコードを構成して、 sysadmin メールボックス宛てのメールがセキュリティの高いUNIXメインフレームに明示的にルーティングされ、 sales 宛てのメールが全く異なる、セキュリティの低いサーバーにルーティングされるようにすることができました。リモートサーバーが電子メールを配信したい場合、その1人のユーザーの受信トレイの正確なハードウェアの宛先を見つけるために、電子メールアドレスのローカルパート (@記号の前の文字列) についてDNSに具体的に照会していました。
拡張性のない悪夢
MBレコードの運用の現実は、完全なスケーリングの惨事でした。5,000人の従業員を抱える中規模の企業ネットワークを管理するには、標準のメールルーティングを処理するだけでも、システム管理者が5,000の個別の、手動で入力されたDNSレコードを維持する必要がありました。新しい従業員が雇用されたり解雇されたりするたびに、コアのDNSゾーンファイルを編集し、SOAシリアルを増やし、メールボックスをプロビジョニングするだけのためにグローバルインターネット全体に変更を伝播させる必要がありました。これによりゾーンファイルは管理不能なサイズに膨れ上がり、初期のDNSリゾルバに極端な処理負荷 (Processing Load) をかけました。
アプリケーション層への委任
エンジニアたちは、DNSがユーザーレベルのIDを管理するための間違ったプロトコルであることにすぐに気付きました。業界はMBの概念を完全に放棄し、確固たるアーキテクチャの境界を確立しました。今日、DNS (MXレコードを介して) は、組織のMail Transfer Agent (MTA) の「玄関」まで電子メールパケットを到達させることのみに責任を持ちます。接続が確立されると、Postfix、Exim、またはMicrosoft Exchangeなどのアプリケーション層ソフトウェアが引き継ぎ、内部データベースまたはActive Directoryを使用してアドレスのローカルパートを解析し、ペイロードを正しい内部受信トレイに配信します。最新の本番ネットワークでMBレコードが解決されることはありません。