SRVレコードは、サービス問い合わせに対して、それを提供するサーバ情報を返答するものでした。DNSの役割が、ホスト名やIPアドレスの解決以外にも展開されていることを象徴していましたが、さらに電話番号をも管理下に置いてしまおうというのが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には多くの期待が寄せられています。
ENUMで使用する電話番号は、正確には「E.164番号」と呼ばれる国番号付きの番号を使用します。「03-1234-5678」(0AB~J番号)を使用している場合、日本国コードを付けた「+81-3-1234-5678」がE.164番号になります。
E.164番号からメールアドレスなどのURIを得る手順を説明します。
E.164番号からDNSを見つけるために、次のような6つのステップでドメイン名に置き換えます。
参考:
RFC 2916「E.164 number and DNS」
http://www.rfc-editor.org/rfc/rfc2916.txt
この手順はまさにIPアドレスの逆引きドメインを設定した際に用いたものと同じで、2ndレベルドメインにin-addrではなくe164を用いることでE.164番号のドメイン名であることを示します。
ドメイン名からDNSサーバを見つける手順は、第4回で紹介した逆引きの仕組みと同様、ドメインツリーが使用され、対象のノードを探し当てます。
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. |
リスト2 NAPTRレコードの例 |
NAPTRレコードのフォーマットは、以下のようになります。順番に説明します。
$ORIGIN X.X.X.X.X.X.X.X.X.X.X.e164.arpa. |
リスト2の102の部分です。多数のNAPTRレコードが設定されている場合、数値の小さいものからレコードを処理します。preferenceより優先されます。符号なし16bit値(0〜65535)が指定可能です。
リスト2では10になっています。多数のNAPTRレコードが設定されており、orderに同じ値が設定されているレコードが複数ある場合、preferenceの数値の小さいものからレコードを処理します。符号なし16bit値(0〜65535)が指定可能です。
リスト2の「"u"」の部分です。flagsでは次のDNS検索アクションを指定できますが、ENUMにおいては「"u"」(または「"U"」)を指定して問い合わせが反復しないようにします。
S or s:次にSRVレコードを参照
A or a:次にAまたはAAAAレコードを参照
U or u:最終結果としてURIを出力
P or p:プロトコルに依存する
リスト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
リスト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. |
上記のNAPTRレコード問い合わせを行ったDNSクライアントは、URIとしてsip:12345678@sip.example.jpを生成します。NAPTRレコードの解釈はSRVレコードと同様、クライアント側で行われます。
リスト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が広く普及すれば、電話番号からメールアドレスやWebページのURLなど、さまざまなサービスのURIを引き出すことが可能になります。その一方で、新たなプライバシー問題の火種になることも懸念されています。
こうした課題があるにもかかわらずENUMが取りざたされるのは、IP電話サービスの普及と密接な関係があるからです。IP電話事業者同士や既存の電話網との相互接続にENUMを利用することで、IP網から電話網への発着信が円滑になることが期待できます。
現在、ENUMに関する技術仕様はほぼ決定しており、世界各国で運用トライアルが行われています。日本国内ではETJP(ENUMトライアルジャパン)(http://etjp.jp/)の活動が知られており、Webページでは活動内容が公開されています。
インターネットの利便性の向上にDNSの進化は欠かせませんが、一方でDNSの肥大化、複雑化が憂慮されます。しかし、インターネットを一元管理しているといっても過言ではないDNSが、仕様の標準化という点で最も着手しやすいものである以上、こうした技術に追従していくこともDNS管理者の責務なのです。
Copyright © ITmedia, Inc. All Rights Reserved.