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

» 2004年03月09日 00時00分 公開
[鶴長鎮一@IT]
前のページへ 1|2       

電話番号をDNSで管理するENUM

 SRVレコードは、サービス問い合わせに対して、それを提供するサーバ情報を返答するものでした。DNSの役割が、ホスト名やIPアドレスの解決以外にも展開されていることを象徴していましたが、さらに電話番号をも管理下に置いてしまおうというのがENUMです。

ENUMとは

 ENUMを導入することで、メールアドレスやWebページのURLといったサービスアプリケーションのURIを、電話番号を検索キーにして引き出すことができます。つまり、相手の電話番号1つで、メールアドレス、Webページアドレス、VoIPで使用するSIPアドレスさえもDNSで返答可能にしようというものです。

 IP電話はその名のとおり、電話機にIPアドレスが振られています。しかし、電話をかける際は相手がIP電話であっても、IPアドレスではなく「03-XXXX-XXXX」のような「0AB~J番号」を利用します。IP電話提供者側が電話番号とIPアドレスを変換する仕組みを用意しており、その提供事業者内であれば、電話をかける側はIP電話であることを意識することなく電話をかけられるというわけです。提供事業者をまたがる場合や、IP電話同士ではなくIP電話から公衆網への接続(あるいはその逆)では、複雑な手順を事業者間で準備する必要があります。

 ENUMは、IP電話提供事業者間接続の苦労を軽減すると期待されています。電話番号は巨大な番号体系を持っていますが、IPアドレスと同様にドメインツリーを用いた分散管理が可能になるなど、DNSには多くの期待が寄せられています。

E.164番号の生成

 ENUMで使用する電話番号は、正確には「E.164番号」と呼ばれる国番号付きの番号を使用します。「03-1234-5678」(0AB~J番号)を使用している場合、日本国コードを付けた「+81-3-1234-5678」がE.164番号になります。

 E.164番号からメールアドレスなどのURIを得る手順を説明します。

 E.164番号からDNSを見つけるために、次のような6つのステップでドメイン名に置き換えます。

  1. 国番号付きのE.164番号を用意
    例:+81-3-1234-5678
  2. 先頭の「+」以外で、数字でない文字を取り除く
    例:+81312345678
  3. 数字以外の文字を取り除く(注)
    例:81312345678(
  4. 数字の間にドット(ピリオド)を挿入
    例:8.1.3.1.2.3.4.5.6.7.8
  5. 数字の並びを反転
    例:8.7.6.5.4.3.2.1.3.1.8
  6. 行末に「.e164.arpa」を付加
    例:8.7.6.5.4.3.2.1.3.1.8.e164.arpa
注:2と3を同一ステップにまとめないのは、将来「+」以外の識別が必要なサービスが登場した場合を考慮しているためです。

参考:
 RFC 2916「E.164 number and DNS」
 http://www.rfc-editor.org/rfc/rfc2916.txt

 この手順はまさにIPアドレスの逆引きドメインを設定した際に用いたものと同じで、2ndレベルドメインにin-addrではなくe164を用いることでE.164番号のドメイン名であることを示します。

 ドメイン名からDNSサーバを見つける手順は、第4回で紹介した逆引きの仕組みと同様、ドメインツリーが使用され、対象のノードを探し当てます。

NAPTRレコードの採用

 IPアドレスの逆引きドメインにはPTRレコードを使いますが、ENUMではNAPTR(Naming Authority Pointer)レコードを使用します。リスト2では、E.164番号+81-3-1234-5678への問い合わせに対し、メールアドレス「foo@example.jp」とWebページのURL「www.example.jp」を返します。

$ORIGIN 8.7.6.5.4.3.2.1.3.1.8.e164.arpa.
  IN  NAPTR  102 10  "u" "E2U+msg:mailto"  "!^.*$!mailto:foo@example.jp!"  .
  IN  NAPTR  102 10  "u" "E2U+web:http"    "!^.*$!http:www.example.jp!"    .
リスト2 NAPTRレコードの例

NAPTRレコードのフォーマット

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

$ORIGIN X.X.X.X.X.X.X.X.X.X.X.e164.arpa.
  IN  NAPTR  order  preference  service   flags  regexp  replacement

  • order

リスト2の102の部分です。多数のNAPTRレコードが設定されている場合、数値の小さいものからレコードを処理します。preferenceより優先されます。符号なし16bit値(0〜65535)が指定可能です。

  • preference

リスト2では10になっています。多数のNAPTRレコードが設定されており、orderに同じ値が設定されているレコードが複数ある場合、preferenceの数値の小さいものからレコードを処理します。符号なし16bit値(0〜65535)が指定可能です。

  • flags

リスト2の「"u"」の部分です。flagsでは次のDNS検索アクションを指定できますが、ENUMにおいては「"u"」(または「"U"」)を指定して問い合わせが反復しないようにします。

S or s:次にSRVレコードを参照
A or a:次にAまたはAAAAレコードを参照
U or u:最終結果としてURIを出力
P or p:プロトコルに依存する

  • service

リスト2の「"E2U+msg:mailto"」および「"E2U+web:http"」です。提供するサービスを

Protocol+ResolutionService

の形式で指定します。ENUMの場合、ProtocolにはE2U(ENUM to URI)を、ResolutionServiceにはサービスごとに定められた別名(注)を指定します。

SIPサービス:E2U+sip
H.323サービス:E2U+h323
電子メールサービス:E2U+msg:mailto
Webサービス:E2U+web:http

注:ResolutionServiceの指定については、IETFのドキュメント「Telephone Number Mapping (enum)」(http://www.ietf.org/html.charters/enum-charter.html)を参照。
  • regexp

リスト2の「"!^.*$!mailto:foo@example.jp!"」および「"!^.*$!http:www.example.jp!"」の部分です。E.164番号からURIを生成するための置換文字列を指定します。

$ORIGIN 8.7.6.5.4.3.2.1.3.1.8.e164.arpa.
  IN  NAPTR  102 10  "u" "E2U+ship"    "!^+813(.*)$!sip:\1@sip.example.jp!"  .

上記のNAPTRレコード問い合わせを行ったDNSクライアントは、URIとしてsip:12345678@sip.example.jpを生成します。NAPTRレコードの解釈はSRVレコードと同様、クライアント側で行われます。

  • replacement

リスト2の「.」です。E.164番号からURIを生成するための置換文字列を指定します。ただし、regexpが空ではなく、replacementが「.」の場合は単にドメインを返します。

参考:
▼RFC 3403「Dynamic Delegation Discovery System(DDDS)」
 http://www.rfc-editor.org/rfc/rfc3403.txt
▼ENUM研究グループ報告書 2003年5月23日(030602D)
 http://www.nic.ad.jp/ja/enum/report/enum-report2003.pdf

ENUM普及の課題

 ENUMが広く普及すれば、電話番号からメールアドレスやWebページのURLなど、さまざまなサービスのURIを引き出すことが可能になります。その一方で、新たなプライバシー問題の火種になることも懸念されています。

 こうした課題があるにもかかわらずENUMが取りざたされるのは、IP電話サービスの普及と密接な関係があるからです。IP電話事業者同士や既存の電話網との相互接続にENUMを利用することで、IP網から電話網への発着信が円滑になることが期待できます。

 現在、ENUMに関する技術仕様はほぼ決定しており、世界各国で運用トライアルが行われています。日本国内ではETJP(ENUMトライアルジャパン)(http://etjp.jp/)の活動が知られており、Webページでは活動内容が公開されています。


 インターネットの利便性の向上にDNSの進化は欠かせませんが、一方でDNSの肥大化、複雑化が憂慮されます。しかし、インターネットを一元管理しているといっても過言ではないDNSが、仕様の標準化という点で最も着手しやすいものである以上、こうした技術に追従していくこともDNS管理者の責務なのです。


前のページへ 1|2       

Copyright © ITmedia, Inc. All Rights Reserved.

RSSについて

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

メールマガジン登録

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