Tweet

　多くのサイトは、「ftp.example.jp」のようにサービス名を別名にしたホスト名を用いることで、サーバを見つけやすくしています。安易な方法ですが、実はRFC 2219（http://www.rfc-editor.org/rfc/rfc2219.txt）として広く推奨されています（表1）。

　これ以外のサービスについても、プロトコル仕様書に別名を提案することが定められています。

サービスの情報を通知するSRVレコード

　RFC 2219の別名を用いる方法では、サービスとサーバの完全な対応付けができないことは明らかです。例えば、HTTPサービスがTCP 80番ポートではなく8080番で動作している場合、RFC 2219の方法ではポート番号まで通知することは期待できません。

　そこで現在検討されているのが、DNSのSRVレコードを用いた方法です。これは、ホスト名やIPアドレスだけでなく、インターネットアプリケーションに必要な情報を盛り込んでしまおうというものです。

■SRVレコードが実現すること

　SRVレコードにより、次のようなことが可能となります。

• 負荷分散サービスの提供
  
• 冗長性の確保
  
• サービスポート番号の通知

　簡単な例を見てみましょう。これまでに紹介したBIND 9のゾーンファイルでは、ホスト名に対するIPアドレス、IPアドレスに対するホスト名の対が並びます。SRVレコードでは、サービスに対してそのサービスを提供するホスト名とそれに関する情報を指定します。example.jpドメインのFTPサービスの記述は以下のようになります。

　SRVレコードを理解するDNSクライアントが、example.jpドメインのFTPサーバの問い合わせを行った場合、まずserver01.example.jpのTCP 21番ポートに対してFTP要求を行い、server01がダウンしている場合はserver02.example.jpにFTP要求を行います。

　これだけの記述で、server01／server02.example.jpというホスト名を知らなくても、example.jpでFTPサービスを提供しているサーバを（しかも冗長性を伴って）見つけることが可能です。いくつかの点で、MXレコード（第3回参照）に似ている面があります。

■SRVレコードのフォーマット

　SRVレコードのフォーマットは、以下のようになります。順番に説明します。

• _Service._Proto.Name
  リスト1の「_ftp._tcp.example.jp.」の部分です。サービスの別名の前に下線（_）を付けたもの（_ftp）と、使用するプロトコルの前に下線を付けたもの（_tcpまたは_udp）を「.」で連ね、最後にドメイン（example.jp.）を「.」で連結します。
  
  サービスの別名やプロトコル名にはRFC 1700（http://www.rfc-editor.org/rfc/rfc1700.txt）に定義されているものや、自サイト固有の名称を使用します。example.jpドメインのSMTPサービスについての記述であれば、
  
  

  _smtp._tcp.example.jp.

  
  のようになります。
  
  Serviceは大文字・小文字の区別が必要ですが、Protoは大文字・小文字の区別はなく、_TCP（または_UDP）でも同義となります。
  
  
• TTL
  リスト1の例では省略されています。TTLは、これまでに何度も登場しているキャッシュ生存期間の指定です。ほかのレコードと同様、省略が可能です。
  
  
• Class
  リスト1の例の「IN」の部分です。SRVレコードでは「IN」を指定します。
  
  
• Priority
  リスト1では1および2になっています。同一サービスに対して複数のサーバが指定されている場合、値が小さい方を優先します。同じPriorityが指定されている場合は、次のWeightフィールド値が参照されます。
  
  Priorityは、符号なし16bit値（0〜65535）が指定可能です。MXレコードのプリファレンス値（第3回参照）と同様、サービスの冗長化を実現します。
  
  
• Weight
  リスト1では0になっています。
  
  同一サービスに対して複数のサーバが指定されており、それぞれのPriorityフィールドに同じ値が指定されている場合は、Weight値で負荷分散を実現します。符号なし16bit値（0〜65535）が指定可能で、0の場合は負荷分散を行いません。
  
  以下のように設定すると、server02はserver01の2倍の要求が行われます。
  
  

  _ftp._tcp.example.jp.   IN  SRV 1   1   21  server01.example.jp _ftp._tcp.example.jp.   IN  SRV 1   2   21  server02.example.jp

  
  第3回で紹介したDNSラウンドロビンでは、DNSサーバ自身が順序付けを行い、クライアントに応答します。SRVレコードでは、クライアントがWeight値の合計と乱数を用いて、接続するサービス対象を選択します。
  
  
• Port
  リスト1では21になっています。Portフィールドは、サービスを提供するポート番号を指定します。符号なし16bit値（0〜65535）が指定可能です。
  
  
• Target
  リスト1ではserver01／server02.example.jp。サービスを提供しているサーバのホスト名です。
  
  このホスト名に対しては、必ずAレコードでIPアドレスが指定されている必要があります。CNAMEで指定されたホスト名を用いることはできません。
  
  以下の例のように、ホスト名ではなく「.」とした場合は、サービスが利用不可であることを意味します。
  
  

  _ftp._tcp.example.jp.   IN  SRV 0   0   0   .

　SRVレコードを利用して冗長化と負荷分散を実現するには、以下のようなゾーンファイルを用意します。

　example.jpドメインに対してSRVレコード対応クライアントからHTTPサービスの問い合わせが行われると、Priorityフィールドの値が小さい（1）と（2）が評価され、（1）：（2）＝3：1の比率で接続先サーバを選択します。ホストbig／smallが両方とも停止している場合は、（3）が評価されます。

　SRVレコード未対応のクライアントからの問い合わせには、（4）が使用されます。（5）と（6）は、HTTP以外のサービスを無効にしています。

■SRVレコードの現状

　大変便利なSRVレコードですが、多くの機能がクライアントに依存しています。現時点でSRVレコードをサポートしているクライアントはごくわずかで、Internet ExplorerやMozillaは対応していません。

　なお、Active DirectoryがSRVレコードを利用しています。

1/2

Index 実用 BIND 9で作るDNSサーバ 　第14回　DNSの拡張仕様、SRVレコードとENUM

Page 1 サービスの情報を通知するSRVレコード 　SRVレコードが実現すること 　SRVレコードのフォーマット 　SRVレコードによる負荷分散と冗長化 　SRVレコードの現状 　 Page 2 電話番号をDNSで管理するENUM 　ENUMとは 　E.164番号の生成 　NAPTRレコードの採用 　NAPTRレコードのフォーマット 　ENUM普及の課題

連載 実用 BIND 9で作るDNSサーバ

	連載：Heartbeatでかんたんクラスタリング（連載中） オープンソースソフトウェアの「Heartbeat」を使ってHAクラスタを実現し、サービスを「落とさない」仕組みを実現します
	特集：Apache 2.2でWebサイトをパフォーマンスアップ！ 最新安定版Apache 2.2は、何が変わったのか？ 最新のApacheを新機能の使い方とともに解説する
	連載：実用 Apache 2.0運用・管理術（全8回） 本連載では、Apache 2.0の運用や管理方法を解説する。まず必須設定と基本的なセキュリティ対策を行い今後の運用に備える
	連載：実用 BIND 9で作るDNSサーバ（全15回） 本連載では、BIND 9の構築／運用方法を解説していく。実際に役立つことを目的に、セキュリティや大規模運用などのテーマを取り上げていく
	連載：実用qmailサーバ運用・管理術（全14回） 本連載を通して、qmailによるメールサーバの高度な構築・運用・管理術を紹介。SPAM対策やML管理からサーバでのウイルスチェックなどまで
	特集：Samba 3.0の全貌 改訂版 Samba 3.0リリースから8カ月。ここであらためて、Samba 3.0系列の新機能、インストール方法、国際化の現状を解説する
	more

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）

RSSフィード