連載
» 2004年03月09日 00時00分 公開

実用 BIND 9で作るDNSサーバ(14):DNSの拡張仕様、SRVレコードとENUM (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サービスの記述は以下のようになります。

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

server01.example.jp.    IN  A   192.168.20.31
server02.example.jp.    IN  A   192.168.20.32
リスト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.
_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   .

参考:
▼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)
_http._tcp.example.jp.  IN  SRV 1   1   80  small.example.jp. (2)
_http._tcp.example.jp.  IN  SRV 2   0   8080    backup.example.jp. (3)

big.example.jp.         IN  A   192.168.20.41
small.example.jp.       IN  A   192.168.20.42
backup.example.jp.      IN  A   192.168.20.43

www.example.jp.         IN  CNAME big.example.jp. (4)

*.tcp                   IN  SRV 0   0   0   . (5)
*.udp                   IN  SRV 0   0   0   . (6)
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 次のページへ

Copyright© 2017 ITmedia, Inc. All Rights Reserved.

@IT Special

- PR -

TechTargetジャパン

この記事に関連するホワイトペーパー

RSSについて

アイティメディアIDについて

メールマガジン登録

@ITのメールマガジンは、 もちろん、すべて無料です。ぜひメールマガジンをご購読ください。