以前、MX レコードに関する質問をしました (また、SO'ers から受け取った思慮深い回答に感謝します)。問題が解決したので、一歩下がって、そもそも MX レコードが存在する理由を尋ねたいと思います。
具体的には: SMTP が DNS によって特別に扱われるのはなぜですか?
HTTP 用の HX レコードまたは FTP 用の FX レコードはありません。他のすべてのインターネット プロトコルは、DNS の A レコードと問題なく動作するようです。実際、MX レコードに関するウィキペディアの記事には、現在の SMTP 仕様では、受信者の MX レコードが存在しない場合、サーバーは A レコードにフォールバックする必要があると記載されています。また、DNS 以前の世界で SMTP が作成したいくつかの調整についても言及していますが、それは 25 年前のことです。MX レコードは本当に必要ですか?
MXSMTPトラフィックuser@domainをそのドメインの他のトラフィックに別の方法でルーティングする必要があり、SRVレコードがまだ発明されていなかったため、レコードが使用されました。
http://example.com/プレフィックスなしでブラウザに入力してwwwも、必要なWebサイトにアクセスできるという現代の慣習は、実際には少し奇妙です。より詳細に説明するために、このプレフィックスなしのアクセスを実現するためにゾーンが通常どのように設定されるかを検討してください。
$ORIGIN example.com
@ IN A 192.168.1.1
IN MX mail.example.com
www IN A 192.168.1.1
mail IN A 192.168.1.2
したがって、アドレス指定されたトラフィックはexample.com、使用中のプロトコルに関係なく、そのIPアドレスに送信されます（MXレコードを使用するのが電子メールである場合を除く）。
実際には、すべてのアプリケーションでレコードを使用することが望ましいでしょう。そうすればSRV、アプリケーション固有のプレフィックスをすべて削除して、Aレコードを実際の目的（具体的には実際のホスト名をIPアドレスにマッピングする）に使用できます。
SRVレコードがこのように使用された場合、そのゾーンファイルは代わりに次のようになります。
$ORIGIN example.com
_http._tcp IN SRV 0 0 80 www.example.com
_smtp._tcp IN SRV 0 0 25 mail.example.com
www IN A 192.168.1.1
mail IN A 192.168.1.2
ドメインのプライマリレコードが実際にHTTPサービス用であるというこの仮定は、 VerisignのSiteFinder「サービス」が2003年に（簡単に）導入されたときと同じくらい多くの問題を引き起こしAた理由の一部でもあります。不明なドメインと独自のアドレスの1つを返すことで、Verisignは、DNSルックアップが失敗した場合に、他のアドレスデータベースメカニズムにフェイルオーバーできると想定していたあらゆる種類のプロトコルを破りました。A
MX レコードの背後にある主な目的は、ドメイン全体の特定のプロトコルを処理するマシンを指定する機能と、(異なる優先順位で) バックアップ メール サーバーを指定する機能です。これにより、1 つのサーバーに障害が発生した場合でもアクセスできます。そのドメインに電子メールを配信する次のサーバー。どちらも、完全な名前をホストに直接マップするプレーンな A レコードでは実行できません。
Frank が指摘するように、 SRV レコード(25 年前ではなく 8 年前の日付)で実行できるようになりました。当時、他に大量に利用できる標準プロトコルはあまりありませんでした。
他のすべてのインターネット プロトコルは、DNS の A レコードと問題なく動作するようです。
まあ、SRV レコード タイプはそれらのために利用可能です。
おそらく、SMTP が現在作成されている場合は、それを使用するでしょう。
「歴史的理由」の説明を決しておろそかにしないでください。80 年代初頭には、SMTP は、サイト全体をマップするために利用可能でなければならない唯一の公に知られているプロトコルであり、DNS ルックアップは多くのシステムで共通の HOSTS ファイルを使用して行われていました。
バックアップ エクスチェンジャの指定を許可することに加えて、すべてのドメインが独自のメール サーバーを持っているわけではないことに注意してください。そのため、別のドメインに存在するメール サーバーを、メール交換を許可されたものとして指定して、管理メッセージおよびシステム メッセージがアドレス指定されるようにする必要があります。ポストマスター、ルート、または DNS WHOIS レコードにリストされている技術/管理連絡先は、現在のドメインに存在しない場合でも配信できます。
ftp と http の場合、これらのサービスは MX のようなアウトバウンド接続を開始せず、公式の連絡先と見なされないため、これは必要ありません。