グローバルSRVレコードチェッカー
標準のAレコードおよびAAAAレコードがドメイン名をIPアドレスに変換することに限定されているのに対し、SRV (Service) レコードははるかに複雑です。RFC 2782で定義されているSRVレコードは、特定のネットワークアプリケーションに対する正確なホスト名、プロトコル、および正確なポート番号を定義する標準化された方法を確立しています。これらはエンタープライズのサービスディスカバリのバックボーンであり、Microsoft Active Directory、SIP/VoIPルーティング、XMPPインスタントメッセージング、および大規模なマルチプレイヤーサーバーアーキテクチャ ( _minecraft._tcp.example.com の解決など) で頻繁に使用されています。
構文とポートバインディング (Port Binding)
SRVレコードは、その厳密なフォーマット構造によって瞬時に認識できます。レコード名は、サービスを示すアンダースコアで始まり、トランスポートプロトコルを示すアンダースコアが続き、ベースドメインに追加される必要があります (例: _sip._tls.example.com)。生成されたペイロードは、接続するクライアントに「優先度 (Priority)」「重み (Weight)」「ターゲットのポート番号 (Port)」「正規のターゲットホスト名 (Hostname)」の4つの特定のデータポイントを提供します。これにより、管理者はエンドユーザーにポート番号を記憶させてクライアントに入力させることなく、非標準ポートを使用して単一のIPアドレスで複数の異なるサービスを実行できます。
ネイティブなフェイルオーバーと重み付き負荷分散
SRVレコードの最も強力な機能は、ネイティブな多層ルーティングロジックです。優先度 (Priority) の整数はMXレコードと全く同じように機能し、接続するクライアントは常に最も優先度が低い (数値が小さい) サーバーとのハンドシェイクを最初にネゴシエートしようと試みます。これにより即時のフェイルオーバー冗長性が確立されます。複数のレコードが全く同じ優先度を共有している場合、重み (Weight) の整数がトリガーされます。これは比例的なロードバランサーとして機能します。サーバーAの重みが75でサーバーBの重みが25の場合、クライアントアプリケーションは新しい接続の75%をサーバーAにルーティングします。これにより、エンジニアはさまざまなハードウェア容量を持つクラスター全体にトラフィックをインテリジェントにルーティングできます。
HTTPがSRVレコードを無視する理由
ジュニア開発者からよくある質問は、なぜWebトラフィック (HTTP/HTTPS) はネイティブの負荷分散を実現するためにSRVレコードを利用しないのかということです。その答えは純粋に歴史的なものです。SRVレコードが標準化された頃には、HTTPはポート80で、HTTPSはポート443で厳密に動作するというアーキテクチャの慣例が、すでにすべてのWebブラウザに普遍的にハードコードされていました。WebをSRVルックアップに移行することは、わずかな利益のために膨大な解決ペナルティ (追加のラウンドトリップの必要性) を追加することになっていたでしょう。代わりに、HTTPはアプリケーションレイヤーのロードバランサーとAnycast IPルーティングに依存しています。