SRVレコード完全ガイド｜仕組み・書式・優先度/重みの設定と運用上の注意点

2025年11月20日 最終更新日時 : 2025年11月20日 エバープレイ編集部

SRVレコードとは — 概要

SRV（Service）レコードは、DNS（Domain Name System）において特定のサービスが稼働しているホスト名とポートを示すためのリソースレコードです。従来のA/AAAAレコード（名前→IP）やMXレコード（メール交換サーバ）と同様に、サービスの発見（service discovery）や負荷分散・冗長化の実装に用いられます。SRVレコードはRFC 2782で定義されており、サービス名とプロトコル、優先度・重み・ポート・ターゲットホスト名を一つのレコードで表現します。

レコードの書式と意味

SRVレコードの典型的な名前は次のようになります。

  • _service._proto.example.com. IN SRV priority weight port target.

各フィールドの意味は以下の通りです。

  • _service：サービス名（例：_sip、_ldap、_xmpp）。アンダースコアで始めるのが慣例・推奨。
  • _proto：使用プロトコル（_tcpや_udpなど）。
  • priority（優先度）：数値。小さい値ほど優先度が高く、まず低い値のレコード群が選択されます（フェイルオーバーの制御）。
  • weight（重み）：同一の優先度を持つ複数レコード間での相対的な選択確率を示します。0以上の整数で、選択は重みに比例して行われます（負荷分散の調整）。
  • port（ポート番号）：サービスが待機しているTCP/UDPポート（0〜65535の16ビット値）。通常はサービス固有のポート番号を指定します。
  • target（ターゲット）：接続先ホスト名（FQDN）。この名前はA/AAAAレコードで解決される必要があります。RFC上ではCNAMEを使うべきではないとされています。

選択アルゴリズム（優先度と重みの扱い）

SRVの選択手順はRFC 2782に規定されています。概要は以下の通りです。

  • まず最も小さい（数値の低い）優先度のレコード群を集める。別の優先度のレコードは無視する。
  • その集合に複数のレコードがある場合、重み（weight）に従って選択する。重みは相対値のため、合計重みに対する各レコードの比率で確率的に選択される。
  • 選ばれたターゲットに対してA/AAAAルックアップを行い、実際の接続を確立する。

例えば、同一優先度で3レコードがあり、それぞれの重みが10、20、70ならば、選択確率はそれぞれ10%、20%、70%になります。

具体例（BINDのゾーンファイル形式）

簡単なゾーンファイルでの記述例：

_sip._tcp.example.com.. IN SRV 10 60 5060 sip1.example.com.
_sip._tcp.example.com.. IN SRV 10 20 5060 sip2.example.com.
_sip._tcp.example.com.. IN SRV 20 0 5060 backup-sip.example.com.

この例では、優先度10のレコード群が優先され、sip1は60/80、sip2は20/80の割合で選択されます（合計80）。優先度20のbackup-sipは、優先度10の全ホストが利用不能な場合にのみ使用されます。

ターゲット名とA/AAAA、CNAMEの扱い

SRVのtargetには基本的にFQDNを指定し、そのFQDNがA（IPv4）やAAAA（IPv6）で解決される必要があります。RFCではSRVのターゲットとしてCNAMEは避けるべき（ターゲットは必ず正引き可能なホスト名であるべき）としています。実装によってはCNAMEを許容するものもありますが、互換性のためターゲットには直接A/AAAAを持つ名前を使うことが推奨されます。

なお、RFCでは特殊ターゲットとして「.」（ドット）を指定することによりそのサービスが利用不可能であることを示す方法が定義されています（サービスなしを表す）。

よく使われる用途とサービス例

  • SIP（VoIP）: _sip._tcp / _sip._udp でSIPサーバの発見。
  • XMPP（チャット）: _xmpp-client._tcp など。
  • LDAPやActive Directory: ADはSRVレコードを積極的に利用します（例: _ldap._tcp.dc._msdcs.example.com）。
  • Kerberosやその他の社内サービス: サービスディスカバリやフェイルオーバー設定。
  • ゲームやカスタムプロトコル: Minecraftサーバなど、一部アプリはSRVを使ってポートを自動発見します。

設定時の注意点と落とし穴

  • サービス名の先頭にアンダースコア：多くのGUIや管理者が忘れがちですが、RFC準拠でサービス名とプロトコルはアンダースコアで始めるのが正しい表記です（例：_sip._tcp）。
  • CNAMEとの混同：SRVのターゲットにCNAMEを使うと互換性問題を招く場合があるため避ける。
  • クライアントの対応：全てのクライアントアプリケーションがSRVをサポートしているわけではありません。例えばHTTPは従来SRVを使わないケースが多く、別途SVCB/HTTPSのような新しい仕組みが提案されています。
  • DNSプロバイダのUI：ProviderによってはSRVの入力方法が異なる（サービス名・プロトコルを別入力にする等）ため、形式とホスティング側の要求を確認する。
  • ヘルスチェックと本当の可用性：DNSレベルの重みや優先度は単純な分配・フェイルオーバーだが、実際のサービス健全性を反映しないことがある。健全性判定は別途ヘルスチェックやロードバランサで行うのが現実的。

運用とトラブルシューティング

SRVの動作確認やデバッグにはdigやnslookupが有用です。例：

dig +short SRV _sip._tcp.example.com

返ってくる形式は「priority weight port target」の並びになります。問題がある場合は、ターゲットのA/AAAAレコードが正しく存在するか、TTLやレコードの反映遅延、DNSSEC署名の有無、DNSキャッシュの影響などを確認してください。また、クライアント側がSRV問い合わせを行っているか（アプリケーションの実装仕様）も重要です。

セキュリティと最新の動向

SRV自体は機能的な情報を返すのみで、認証や暗号化を伴いません。TLS等を使うサービスではSRVで見つけたホストに対してTLS接続を確立し、証明書チェーンやピンニングなどでセキュリティを担保します。近年、HTTP系ではSRVではなくSVCB/HTTPSの利用が提案・採用されつつあり、よりTLSや接続の最適化に寄与する仕組みが整備されてきています（導入状況はクライアント・サーバ双方の対応に依存します）。

まとめ（実務で押さえるべきポイント）

  • SRVはサービス名・プロトコル・優先度・重み・ポート・ターゲットを通じてサービス発見と簡易なロードバランシング/フェイルオーバーを実現する。
  • ターゲットはA/AAAAで解決できるホスト名を指定し、CNAMEは避けるのが安全。
  • 優先度（小さいほど優先）と重み（確率的分配）を正しく設定することで期待する挙動を作れる。
  • 全てのクライアントがSRVを参照するわけではないため、利用するサービスの実装仕様を確認すること。
  • DNSの反映遅延、TTL、DNSSEC、プロバイダUIの仕様に注意して設定・運用する。

参考文献

カテゴリー
IT
前の記事
Magdalena Kožená（マグダレナ・コジェナ）｜メゾソプラノの魅力と聴きどころガイドNew!!
2025年11月20日
次の記事
TXTレコードとは？SPF・DKIM・DMARC・ACME対応の設定方法と運用上の注意点ガイドNew!!
2025年11月20日