1. 序論と概要 (Introduction and Overview)
1.1 概要と根拠 (Overview and Rationale)
現在、サーバーに接続するには、サーバーの正確なアドレスを知っているか、ブロードキャストクエリを送信する必要があります。
SRVリソースレコード (SRV RR) は、管理者に以下の機能を提供します：
- 複数サーバーのサポート: 単一のドメインに複数のサーバーを使用
- 柔軟な移行: サービスをホストから別のホストへ簡単に移動
- 主従メカニズム: 一部のホストをサービスの主サーバーとして指定し、他のホストをバックアップとして指定
動作原理 (Working Mechanism)
クライアント (clients) は、特定のドメインの特定のサービス/プロトコルを要求し、利用可能なサーバーの名前を取得します。
本文書での「ドメイン (domain)」という用語は、RFC 1034の厳密な定義に従って使用されます。
本文書で言及される「アドレスレコード (address records)」とは：
- A RR (IPv4アドレスレコード)
- AAAA RR (IPv6アドレスレコード)
- またはそれらの最新の同等物
1.2 定義 (Definitions)
本文書で使用されるキーワードは、[BCP 14] に指定されているように解釈されるべきです：
- MUST: しなければならない
- MUST NOT: してはならない
- SHOULD: すべきである
- SHOULD NOT: すべきでない
- MAY: してもよい
本文書で使用される他の用語は、DNS仕様 RFC 1034 で定義されています。
1.3 適用性の声明 (Applicability Statement)
一般的に、SRVレコードは、関連するプロトコル仕様がクライアントがSRVレコードを使用すべきであることを示すアプリケーションでクライアントによって使用されることが期待されます。
仕様要件 (Specification Requirements)
SRVレコードを使用するプロトコル仕様は、必ず (MUST) 以下を定義する必要があります：
- Serviceフィールドのシンボリック名: SRVレコードのServiceフィールドで使用されるシンボリック名
- セキュリティの考慮事項: 完全なセキュリティの考慮事項を含む
明示的なプロトコル仕様がない場合、サービスSRVレコードを使用すべきではありません (SHOULD NOT)。
1.4 導入例 (Introductory Example)
LDAPサービス発見の例
SRVに対応したLDAPクライアントが、以下の条件を満たすLDAPサーバーを発見したいとします：
- TCPプロトコル (TCP protocol) をサポート
- ドメイン example.com のLDAPサービスを提供
クエリ方法:
_ldap._tcp.example.com
クエリの解析:
_ldap: サービス識別子 (service identifier)_tcp: プロトコル識別子 (protocol identifier)example.com: ターゲットドメイン (target domain)
本メモの末尾近くのサンプルゾーンファイルには、SRVクエリに対する応答リソースレコードが含まれています。詳細は [ARM] 文書を参照してください。
LDAPは例として選択されており、説明目的のみです。本文書で使用されるLDAP例は、LDAPがSRVレコードを使用する推奨方法の権威ある声明とは見なされません。
前述の適用性セクションで説明されているように、推奨される手順については、適切な LDAP文書 を参照してください。
本章のまとめ (Chapter Summary)
本章では、SRVレコードの基本概念と適用シナリオを紹介しました：
- 問題の背景: 従来のDNSはサービス発見と負荷分散を効果的にサポートできない
- 解決策: SRVレコードはサービスの場所、優先度、重み情報を提供
- 適用範囲: 明確なプロトコル仕様のサポートが必要
- 典型的な応用: LDAP、Kerberosなどの分散サービス