SRV レコード(Service Record)
概要
SRV レコード(Service Record) は、特定のサービスを提供するサーバーのホスト名とポート番号を DNS で公開するためのレコードです。RFC 2782(2000年)で定義されており、レコードタイプ番号は 33 です。
MX レコードがメール配送先を指定するのと同様に、SRV レコードは任意のサービスの接続先を指定します。MX レコードとの違いは、ポート番号とプロトコル(TCP/UDP)を明示的に指定できる点です。XMPP(チャット)、SIP(VoIP)、LDAP、Kerberos、Microsoft Active Directory など、サービスの自動検出が必要なプロトコルで広く使われています。
仕組み
SRV レコードはサービス名・プロトコル・優先度・重み・ポート・ターゲットの各フィールドで構成され、クライアントの接続先選択を制御します。
レコードの構造
SRV レコードのオーナー名はサービス名とプロトコルを含む特殊な形式です。
_sip._tcp.example.com. IN SRV 10 60 5060 sipserver.example.com.
| フィールド | 説明 |
|---|---|
| _service | サービス名。IANA に登録されたサービス名をアンダースコア付きで指定する |
| _proto | プロトコル。_tcp、_udp、_tls のいずれか |
| NAME | ドメイン名 |
| Priority | 優先度。値が小さいほど優先される(MX レコードと同じ) |
| Weight | 同一 Priority 内での重み付け。値が大きいほど選択されやすい |
| Port | サービスのポート番号 |
| Target | サービスを提供するサーバーの FQDN。IP アドレスは指定できない |
優先度と重み付けの選択アルゴリズム
クライアントは SRV レコードを次の手順で処理します。
- Priority が最も小さいレコードのグループを選ぶ
- そのグループ内で Weight に基づく確率的な選択を行う
- 選択したサーバーへの接続が失敗した場合、同じグループの次のサーバーを試す
- グループ内のすべてのサーバーが応答しない場合、次に Priority が小さいグループに移る
Weight が 0 のレコードは最も低い選択確率を持ちます。RFC 2782 では、Weight の合計に対する各レコードの Weight の割合で接続先を確率的に選択するアルゴリズムが規定されています。
サービス無効化
Target を .(ルートドメイン)に設定すると、そのサービスが利用できないことをクライアントに通知できます。
_sip._tcp.example.com. IN SRV 0 0 0 .
クライアントはこのレスポンスを受け取ると、そのドメインではサービスが提供されていないと判断し、接続を試みません。
設定例
XMPP、SIP、Microsoft 365 Autodiscover、LDAP など、サービスごとの SRV レコード設定を示します。
XMPP サーバー(クライアント接続)
_xmpp-client._tcp.example.com. IN SRV 5 0 5222 xmpp.example.com.
XMPP クライアントは example.com への接続時にこの SRV レコードを参照し、xmpp.example.com のポート 5222 に接続します。
XMPP サーバー間通信
_xmpp-server._tcp.example.com. IN SRV 5 0 5269 xmpp.example.com.
SIP(VoIP)の冗長構成
Priority と Weight を組み合わせた負荷分散と冗長構成です。
_sip._tcp.example.com. IN SRV 10 60 5060 sip1.example.com.
_sip._tcp.example.com. IN SRV 10 40 5060 sip2.example.com.
_sip._tcp.example.com. IN SRV 20 0 5060 sip-backup.example.com.
Priority 10 のグループでは sip1 が 60%、sip2 が 40% の割合で選択されます。両方に障害が発生した場合、Priority 20 の sip-backup にフォールバックします。
Microsoft 365 の Autodiscover
_autodiscover._tcp.example.com. IN SRV 0 0 443 autodiscover.outlook.com.
Outlook クライアントは SRV レコードを使って Exchange Online の自動構成エンドポイントを検出します。
LDAP サーバーの検出
Active Directory 環境では、ドメインコントローラーの検出に SRV レコードが使われます。
_ldap._tcp.dc._msdcs.example.com. IN SRV 0 100 389 dc1.example.com.
_ldap._tcp.dc._msdcs.example.com. IN SRV 0 100 389 dc2.example.com.
確認方法
dig で SRV レコードを確認するには次のコマンドを使います。
dig SRV _sip._tcp.example.com
出力の ANSWER SECTION に Priority、Weight、Port、Target が表示されます。
;; ANSWER SECTION:
_sip._tcp.example.com. 3600 IN SRV 10 60 5060 sip1.example.com.
_sip._tcp.example.com. 3600 IN SRV 10 40 5060 sip2.example.com.
SRV レコードの Target はホスト名であるため、実際の IP アドレスを知るには追加で A / AAAA レコードを引く必要があります。
dig A sip1.example.com
;; ANSWER SECTION:
sip1.example.com. 3600 IN A 203.0.113.10
Microsoft 365 の Autodiscover SRV を確認するには次のコマンドを使います。
dig SRV _autodiscover._tcp.example.com
Labee Dev Toolbox の DNS API は現在 SRV レコードタイプに対応していないため、dig コマンドで確認します。
よくある問題
SRV レコードのトラブルは、オーナー名の形式ミス、Target への IP 直接指定、TTL の長さに起因するケースが典型的です。
アンダースコア付きのオーナー名を正しく設定していない
SRV レコードのオーナー名は _service._proto.domain の形式です。アンダースコアを省略したり、サービス名を間違えたりすると、クライアントがレコードを発見できません。IANA の Service Name and Transport Protocol Port Number Registry で正確なサービス名を確認します。
Target に IP アドレスを指定している
SRV レコードの Target フィールドには FQDN を指定します。IP アドレスを直接記述するとクライアントが正しく解釈できません。Target が指すホスト名に対して A / AAAA レコードが設定されていることも確認します。
Weight の配分が意図通りに動作しない
Weight による負荷分散はクライアント側の実装に依存します。すべてのクライアントが RFC 2782 の重み付けアルゴリズムを厳密に実装しているわけではなく、一部のクライアントは Weight を無視して Priority のみで選択します。正確な負荷分散が必要な場合はロードバランサーの利用を検討します。
TTL が長すぎてフェイルオーバーが遅れる
SRV レコードの TTL が長いと、サーバー障害時にクライアントが障害サーバーへの接続を試し続けます。冗長構成で運用する場合は TTL を 300〜600 秒 程度に設定して、フェイルオーバーの応答時間を短くします。