DNSの拡張仕様、SRVレコードとENUM：実用 BIND 9で作るDNSサーバ（14）（1/2 ページ）
DNSの用途を拡大すべく、いくつかの拡張仕様の標準化が議論されている。今回は、SRVレコードとENUMという2つの技術について解説する。（編集局）
多くのサイトは、「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] |
| 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サービスの記述は以下のようになります。
_ftp._tcp.example.jp. IN SRV 1 0 21 server01.example.jp. |
| リスト1 SRVレコードの例 |
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 TTL Class SRV Priority Weight Port Target |
- _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. |
第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 . |
参考：
▼RFC 2782「A DNS RR for specifying the location of services」
http://www.rfc-editor.org/rfc/rfc2782.txt
SRVレコードによる負荷分散と冗長化
SRVレコードを利用して冗長化と負荷分散を実現するには、以下のようなゾーンファイルを用意します。
_http._tcp.example.jp. IN SRV 1 3 80 big.example.jp. （1） |
| 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レコードを利用しています。
Copyright © ITmedia, Inc. All Rights Reserved.
注目のテーマ
ITmediaはアイティメディア株式会社の登録商標です。