DNSの拡張仕様、SRVレコードとENUM：実用 BIND 9で作るDNSサーバ（14）（1/2 ページ）

DNSの用途を拡大すべく、いくつかの拡張仕様の標準化が議論されている。今回は、SRVレコードとENUMという2つの技術について解説する。（編集局）

[鶴長鎮一，＠IT]

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

別名	サービス
archie	archie [ARCHIE]
finger	Finger [RFC-1288]
ftp	File Transfer Protocol [RFC-959]
gopher	Internet Gopher Protocol [RFC-1436]
ldap	Lightweight Directory Access Protocol [RFC-1777]
mail	SMTP mail [RFC-821]
news	Usenet News via NNTP [RFC-977]
ntp	Network Time Protocol [RFC-1305]
ph	CCSO nameserver [PH]
pop	Post Office Protocol [RFC-1939]
rwhois	Referral WHOIS [RFC-1714]
wais	Wide Area Information Server [RFC-1625]
whois	NICNAME/WHOIS [RFC-954]
www	World-Wide Web HTTP [RFC-1945]
表1

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

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

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

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

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

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

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

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

*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***

　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レコードのフォーマットは、以下のようになります。順番に説明します。

*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***

• _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サービスについての記述であれば、

*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***

のようになります。

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倍の要求が行われます。

*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***

第3回で紹介したDNSラウンドロビンでは、DNSサーバ自身が順序付けを行い、クライアントに応答します。SRVレコードでは、クライアントがWeight値の合計と乱数を用いて、接続するサービス対象を選択します。

• Port

リスト1では21になっています。Portフィールドは、サービスを提供するポート番号を指定します。符号なし16bit値（0〜65535）が指定可能です。

• Target

リスト1ではserver01／server02.example.jp。サービスを提供しているサーバのホスト名です。

このホスト名に対しては、必ずAレコードでIPアドレスが指定されている必要があります。CNAMEで指定されたホスト名を用いることはできません。

以下の例のように、ホスト名ではなく「.」とした場合は、サービスが利用不可であることを意味します。

*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***

参考：
▼RFC 2782「A DNS RR for specifying the location of services」
　http://www.rfc-editor.org/rfc/rfc2782.txt

SRVレコードによる負荷分散と冗長化

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

*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***

　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レコードを利用しています。