ENUM における DNSsec 問合せの解析

(1)

2004 年度卒業論文

ENUM における DNSsec 問合せの解析

提出日： 2005 年 2 月 2 日

指導：後藤滋樹教授

早稲田大学理工学部情報学科学籍番号： 1G01P048-4

笹川真

(2)

図一覧

2.1 ENUMのイメージ . . . 7

2.2 E.164番号の書式 . . . 8

3.1 DNSsecのイメージ . . . 12

4.1 実験の環境 . . . 15

4.2 網羅的検索中のCPU使用率 . . . 16

4.3 網羅的検索中のメモリ使用率 . . . 17

5.1 階層化のイメージ . . . 18

5.2 各階層への平均問合せ時間-グラフ- . . . 19

6.1 平均DNS問合せ時間の測定環境 . . . 21

6.2 問合せ時間の一般化 . . . 22

6.3 接続品質の目標値 . . . 23

6.4 管理桁数によるCPU使用率の違い . . . 23

(5)

表一覧

2.1 serviceフィールドとURIの例 . . . 10

4.1 実験に使用したマシンの仕様 . . . 16

4.2 網羅的検索中のCPU使用率の最大値と最小値 . . . 16

4.3 網羅的検索中のメモリ使用率の最大値と最小値. . . 17

5.1 各階層への平均問合せ時間-表- . . . 19

5.2 実ステップ数と本来ステップ数の差. . . 20

6.1 自動接続遅延時間 . . . 22

(6)

第 1 章序論

1.1 研究の背景

情報通信技術や情報通信インフラの整備・拡大により、インターネットの普及がますます進んでいる。総務省の発表によると平成15年12月末の時点で日本におけるインターネット利用人口は1500万人近くにも上る。

各ユーザーが高速通信を常時接続性を確保したことで、インターネット上の通信形態はますます多様化している。メールやWEBはもちろん、電話やFAXもインターネット上で利用されるようになった。電話やFAXなどの従来型通信サービスと、メールやメッセンジャーなどのインターネット型通信サービスは、今後さらにインターネット上で融合し、ユーザは多様な通信サービスを利用できるようになる。その代表的な例はIP電話であろう。

このような中で、通信サービスの種類・サービス業者によらず、電話番号という統一的な識別子で通信相手を特定するためのしくみがENUMである。ENUMの国際的な標準化の検討は、

2000年頃からIETFとITU-Tが行っている。各国でENUMのトライアル運用が始まる中、日

本でも2003年にETJP (ENUM Trial Japan)が設立され、ENUMの技術的課題について検討と整理が進められている。

1.2 研究の目的

1.1節で記述したように、インターネットの普及が進み、一人のユーザが多くのインターネット上のサービスを利用するようになり、それに伴い多数のアドレスを保持するようになった。その多数のアドレスの一元管理する効率的な方法として、ENUMはこれからより多くの注目を集め、普及していくはずである。それは現在インターネットサービスプロバイダ各社が独自に提供しているIP電話の普及によってより加速することが予想される。

ENUMという技術がエンドユーザに浸透していく中で、多くの問題が予想される。ENUMを

(7)

第 1 章序論

実現するDNSレコードのNAPTR RRに正規表現の形で登録されたe-mailアドレス、SIPアドレスやWebのURLなどの様々な個人情報が網羅的検索によって安易に収集される可能性がある。また、悪意のあるユーザによって個人情報が改竄されてしまう可能性もある。その改竄を防ぐ手段として第3章において後述するDNSsecが良く知られているが、DNSsecによる署名により、処理に時間がかかり管理者の運用コストがかかり、またエンドユーザの使い勝手が悪くなる可能性がある。その上、DNSのレコードには個人情報を含むため多数のE.164番号を少数のマシンで管理した場合には網羅的検索を受けた場合、そのマシンに大きな負荷がかかる可能性もある。

このような問題意識のもとで、本論文は、多数のE.164番号を管理した場合の、網羅的検索によるマシン負荷での問題、エンドユーザの利便性を考えた場合の階層化による問合せ時間の増加とマシン負荷のトレードオフについて考察するものである。

1.3 本論文で用いる用語の定義

• ENUM

E.164番号をキーとしてDNSを検索し、そのE.164番号に対応するアプリケーションをURI

形式で得る機構。

• E.164番号

ITU-T E.164勧告で規定された電話番号、長さ、唯一性を満たす10進の数字列。外国か

らの着信も可能で国番号を含めて15桁以内の番号。

• DNS : Domain Name System

インターネットに接続された端末の情報を提供する分散データベース。ドメイン名とIPアドレスの対応をとる。

• DNSsec

DNSゾーンに権限を持つ管理者が公開鍵暗号方式を用いて自らのゾーンに署名し、第三者による改竄・騙りを防止する技術

• ZSK : Zone Signing Key

DNSsecでゾーン情報に署名する鍵

• KSK : Key Signing Key

DNSsecでゾーン情報に署名した鍵ZSKに署名する鍵

• DS : Delegation Signer

KSKの公開鍵から作成され、上位ドメイン管理マシンへ登録される

(8)

第 1 章序論

• URI : Uniform Resource Identifiers

インターネット上の各種情報にアクセスする手段(プロトコル)と場所を指定する記述様式。

• NAPTR : Naming Authority Pointer

文字列変換により、ドメインラベルやURIを生成するための書き換え規則を記述するためのDNSリソースレコード。

• リソースレコード(RR : Resource Record)

DNSデータベースの各構成要素。NAPTRもRRの一つ。

• 自動接続遅延時間

IP電話の接続品質を表す用語。信号を選択してから呼び出し音が鳴るまでの時間。

1.4 本論文の構成

本論文は以下の章により構成される

第 1 章序論

本研究の概要について述べる。

第 2 章 ENUM (tElephone NUmber Mapping) ENUMの仕様について述べる。

第 3 章 DNSsec (DNS Security Extension)

DNSsecの仕様について述べる。

第 4 章網羅的検索によるマシン負荷の実験

多数のE.164番号を1台のマシンで管理したときのマシン負荷を実験し、考察する。

第 5 章階層化による問合せ時間の実験

階層化した場合の問合せ時間の変化について実験し、考察する。

第 6 章マシン負荷と階層化のトレードオフの考察

網羅的検索におけるマシン負荷と階層化における問合せ時間の増加のトレードオフについて考察する。

第 7 章結論

本論文のまとめと今後の課題について考察する。

(9)

第 2 章

ENUM (tElephone NUmber Mapping)

2.1 ENUM の概要

ENUMは、電話番号からDNSを用いてインターネット上で利用できるアプリケーションのサービス情報を得る仕組みである。ENUMの簡単なイメージを図2.1に示す。具体的には電話番号を名前空間として、アプリケーションのサービス情報をDNSサーバに登録する。そして電話番号キーとしてDNSサーバに問合せることにより、電話番号に対応付けられたサービス情報を得る。またENUMでは、1つの電話番号に対して複数のサービス情報を登録することが可能である。複数のサービス情報を登録する場合には、優先度や選択の順序を指定することができる。ENUM では電話番号としてE.164番号を、またアプリケーションのサービス情報としてURIを用いる。

図 2.1: ENUMのイメージ

(10)

第 2 章 ENUM (TELEPHONE NUMBER MAPPING)

2.1.1 E.164番号

ENUMで扱う電話番号はE.164番号と呼ばれる電話番号である。E.164番号はITU-Tの勧告に従った電話番号の体系であり、世界的に唯一性を持っている。E.164番号の書式と、例として (03)-5286-3182の電話番号をE.164番号で示したものを図2.2に示す。なお、日本の国番号(Coun- try Code)は81である。

図 2.2: E.164番号の書式

2.1.2 URI (Uniform Resource Identifer)

URIとは、インターネット上の情報資源を特定するための統一された構文を持つ一般的な形式である。URL (Uniform Resource Locator)も含まれる。URIは、スキームと呼ばれる枠組みを表す文字列と、スキームごとに決められた形式を持つスキーム固有部をコロン：で結ぶ書式を取る。スキームは、プロトコル名を用いることが多い。URIの例としては、http://www.

goto.info.waseda.ac.jp/やmailto:sasagawa@goto.info.waseda.ac.jpなどがある。

2.2 ENUM の動作

ENUMはE.164番号をキーとしてDNSを引き、URIへ変換情報をDNSから得る。E.164番号を名前空間にマッピングする方法は、IPアドレスの逆引きアドレスの機能と似ている。以下に電話番号(03)-5286-3182を例にとって様子を示す。

1. 電話番号をE.164番号にする。

+81-3-5286-3182

2. + と数字以外の文字を取り除く。これが2.2.2節で後述する正規表現処理の入力文字列となる。

+81352863182

(11)

3. 数字以外の文字を取り除く。

81352863182

4. 数字間にドット . を挿入する。

8.1.3.5.2.8.6.3.1.8.2 5. 文字列を逆順にする。

2.8.1.3.6.8.2.5.3.1.8

6. 文字列末に .e164.arpa を付加する。

2.8.1.3.6.8.2.5.3.1.8.e164.arpa

こうして得られた文字列をドメイン名とし、DNSにURIを得るための情報を登録する。この ENUMでURIを得るための情報は、DNSのNAPTRというリソースレコード(RR)に登録する。なお過程6で付加する .e164.arpa は、RFC3761でENUM用のドメイン名として提案されており、現在はトライアル用に利用されている。本論文ではこのドメイン名として .e164.jp を利用している。これは、ETJPが会員のトライアル向けに提供しているドメイン名である。

2.2.1 NAPTR RR (Naming Authority PoinTR Resource Record)

NAPTR RRの構成を以下に示す。

IN NAPTR order preference flags service regexp replacement

NAPTR RRの各フィールドについて説明する。

• IN NAPTR

それぞれRRのデータのクラスとタイプを表している。

• order, preference

複数のNAPTR RRが返された場合に、処理順序を示す16bit符号なし整数。小さい値が

優先される。まずorderが比較され、同値の場合はpregernceが評価される。

• flags

正規表現処理やフィールドの解釈を制御する。ENUMのNAPTR RRでは、置換処理後の文字列がURIであることを示す u のみが定義されている。

• service

ENUMで使うプロトコルであるE2U(ENUM to URI)とサービス名を + で結びつけたもの。例を表2.1に示す。

(12)

• regexp, replacement

regexpには正規表現を書く。正規表現処理に関しては次節で説明する。replacementはreg- expがある場合はドット．を書く。

表 2.1: serviceフィールドとURIの例

サービス serviceフィールド URIの例

SIP E2U+SIP sip:sasagawa@sip.goto.info.waseda.ac.jp H.323 E2U+H323 h323:sasagawa@h323.goto.info.waseda.ac.jp

電話 E2U+tel tel:+81352863182

FAX E2U+fax:tel tel:+81352863182

e-mail E2U+email:mailto mailto:sasagawa@goto.info.waseda.ac.jp Web E2U+web:http http://www.goto.info.waseda.ac.jp FTP E2U+ft:ftp ftp://ftp.goto.info.waseda.acjp

2.2.2 正規表現の処理

E.164番号を元に生成されたドメインをキーにDNSに問合せをすると、前節で述べたNAPTR

RRがかえる。そこからサービスに対応したURIを得るにはregexpフィールドに書かれた正規表現を処理しなくてはならない。

正規表現の処理に伴う要素は以下のとおりである。

• 正規表現が適応される文字列(入力文字列)

E.164番号から + と数字以外の番号を取り除いた文字列

2.2節のドメインを作成する過程2の文字列

• 正規表現(そのもの)

regexpフィールドの切り文字 ! で区切られた前の部分

• マッチした場合に置換する文字列

regexpフィールドの切り文字 ! で区切られた後ろの部分

2.3 ENUM 利用の想定されるシーン

ENUMは、E.164番号という世界的に唯一性のある数字列をDNSにマッピングしたことによ

り、URIなどの情報を一元管理するのに向いている。現状の日本のIP電話の相互接続では、事

(13)

業者同士が個別にユーザの電話番号ごとの接続先SIPサーバの情報などを事前に交換している。

したがって、情報の登録、変更のたびに事業者ごとの作業が発生する。今後相互接続者数が増えるにしたがい、この方法は非現実的なものとなる。

ここで、ユーザ情報の登録にENUMを用いることによって、SIPサーバ情報をDNSで一元管理でき、管理が格段に楽になる。また、DNSに登録するE.164番号に該当する番号領域としては、IP電話での利用を目的として割り当てが開始された050で始まる電話番号(050番号)の利用が考えられる。

(14)

第 3 章

DNSsec (DNS Security Extension)

3.1 DNSsec の概要

DNSsecとはDNSゾーンに権利を持つ管理者が、公開暗号鍵技術を用いて、自らのゾーン情

報に署名を行い、ゾーン情報の信頼性を確保するDNSの運用方式である。ゾーン情報の信頼性を確保する為の手段として、ゾーン情報そのものを暗号化する方法も考えられるが、DNS問合せのたびに暗号の復号化の作業が必要になるため効率が大きく低下する。そこで、ゾーン情報の信頼性効率を満たすDNSsecがENUMでは使用されるようになった。簡単なイメージを図3.1に示す。ゾーン情報の署名には2つの鍵、ZSK・KSKを用いる。ZSKはゾーン情報の署名に用いる鍵である。KSKはZSKに署名をする時に使用される鍵である。ゾーン情報の信頼性をZSK を用いて保障し、ZSKの信頼性をKSKを用いて保障する。KSKの信頼性をKSKから作成さ

れたDS (Delegation Signer)を上位ドメイン管理サーバに登録することによって保障する。この

ように連鎖的に信頼を得るしくみを信頼の連鎖(chain of trust)とも言う。

図 3.1: DNSsecのイメージ

(15)

第 3章 DNSSEC (DNS SECURITY EXTENSION)

3.2 DNSsec の動作

client.example.jp を例に、順にその様子を示す。今回は信頼の連鎖(chain of trust)のルートを jp ドメインを管理するDNSサーバとする。

1. jp ドメインを管理するDNSサーバに問合せを出す。

2. jp DNSサーバから情報を取得する。

• example DNSサーバのNSレコード

• example DNSサーバのDSレコード

3. example DNSサーバに問合せを出す。

4. example DNSサーバから情報を取得する。

• ゾーン情報(clientのAレコード)

• 署名済みのゾーン情報

• ZSK (Zone Signing Key)の公開鍵

• 署名済みのZSKの公開鍵

• KSK (Key Signing Key)の公開鍵

5. DSレコードとKSKを比較し、KSKの信頼性を確認する。

6. 署名済みのZSKをKSKで複合化し、ZSKの信頼性を確認する。

7. 署名済みのゾーン情報を複合化し、ゾーン情報の信頼性を確認する。

3.3 DS (Delegation Signer)

DS (Delegation Signer) RRの構成を以下に示す。

IN DS KeyTag Algorithm DigestType Digest DS (Delegation Signer) RRの各フィールドについて説明する。

• IN DS

それぞれRRのデータのクラスとタイプを表している。

(16)

第 3章 DNSSEC (DNS SECURITY EXTENSION)

• KeyTag

署名に用いられた鍵によって作成される。

• Algorithm

署名時に用いられたアルゴリズムの識別子である。

• DigestType

使用されるダイジェストアルゴリズムの識別子である。ダイジェストタイプ値0は予約されており、値1はSHA-1である。

• Digest

委任されたドメイン名の正規名と、それに続くKEYレコードのRDATA (4フィールド全て)について計算される。

DS (Delegation Signer) RRの具体例を示す。

IN DS 13412 5 1 8BA3A6EB184DE159421761899207A51E4F44F35E

3.4 DNSsec が保障する情報

ゾーン情報の第三者による改竄・騙りを検証する。これにより、騙りを許したくないDNSレコードを守ることが可能になる。ENUMが商業利用される場合を考えると、DNSsecはプロバイダ側から消費者側への提供する商品の品質保持を可能とするための大変有効な技術であると考えられる。

(17)

第 4 章

網羅的検索によるマシン負荷の実験

4.1 実験の目的

多数のE.164番号を1台のマシンで管理する状況を作り、網羅的検索を受けた時にマシン負荷

がどのように変化するかを実験し、考察する。

4.2 実験の環境

図4.1に実験の環境を示す。表4.1に実験に使用したマシンの仕様を示す。

図 4.1: 実験の環境

(18)

表 4.1: 実験に使用したマシンの仕様

PC CPU Memory OS 名前解決ソフト

semi1 AMD-K6tm 165MHz 96MB FreeBSD 5.2.1-RELEASE bind9.3.0beta4 dnssec-co Pentium 200MHz 64MB FreeBSD 5.2.1-RELEASE bind9.3.0beta4 secContents Celeron 700MHz 126MB FreeBSD 5.2.1-RELEASE bind9.3.0beta4

4.3 実験の内容

マシンsemi1をターゲットマシンとし、10000件のE.164番号0000. . . 9999を登録したゾーンを作成する。そして、dnssec-co, secContentsの2台に加えて研究室の他実験使用中のPC5台、

計7台の各マシンから0000, 0001, 0002. . . 9997, 9998, 9999の計10000回の問合せを各マシンから行い、その時のCPU使用率とメモリ使用率を測定する。

4.4 実験の結果

次のグラフを得た。

図 4.2: 網羅的検索中のCPU使用率

表 4.2: 網羅的検索中のCPU使用率の最大値と最小値最大値最小値

CPU使用率 52.05% 0%

(19)

図 4.3: 網羅的検索中のメモリ使用率

表 4.3: 網羅的検索中のメモリ使用率の最大値と最小値最大値最小値

メモリ使用率 14.9% 14.9%

4.5 考察

まず、CPU使用率は網羅的検索が開始されると0%だったものが急激に50%以上に増加した。

また、網羅的検索の継続中は常に高い数値を維持していた。後半になってCPU負荷率が階段状に下がっているのは、網羅的検索を行っている7台のマシンの性能の差により、すでに問合せを終了したマシンが発生しているからだと考えられる。よって図4.2よりコンテンツサーバーに高い負荷がかかっていることがわかる。この状況は大変望ましくない。

また、メモリ使用率は網羅的検索が開始された後も同じ数値を保っていた。これは名前解決ソ

フトのbind9.3.0beta4が起動時に必要メモリを固有値で設定し、それよりあふれた場合は応答を

返さないような仕様になっているためだと考えられる。実際問合せを行っているマシンでも返事が返ってこない事態が起こっていた。

これらの結果から、1台のマシンで多数のE.164番号を管理することは非常に問題性が高いと結論づけられる。

(20)

第 5 章

階層化による問合せ時間の実験

5.1 実験の目的

第4章で多数のE.164番号を1台のマシンで管理し、網羅的検索を受けた場合のマシン負荷における危険性を考察した。これに対して、負荷を分散する方法として、権限委譲(delegation：デリゲーション)によって階層化する方法が考えられる。階層化した場合、各マシンに問合せを

する度にDNSsec特有の処理を行わなければならない。その場合における問合せ時間の変化を実

験し、計測・考察する。

5.2 実験の環境

第4章と同様のネットワーク環境、同様のマシン群で行う。階層化のイメージは図5.1の通りである。

図 5.1: 階層化のイメージ

(21)

5.3 実験の内容

ETJP用ルートサーバ, dnssec-co, secContents, semi1の各マシンにNAPTR RRを登録し、

順に権限委譲(delegation:デリゲーション)を行い、目的とするデータを取得するまでに多くの階層を通る必要があるように設定を行う。その上で各マシンに登録したE.164番号への問合せ時間の変化を測定する。

また、secContentsはキャッシュサーバの機能も持つように設定し、secContentsから問合せを出すように設定した。その上で各番号に100回の問合せを行いその平均時間を計測した。

5.4 実験の結果

計測結果は次のようになった。

表 5.1: 各階層への平均問合せ時間-表-

0層 1層 2層 3層

平均値 1767.18msec 3483.49msec 2.7msec 1860.22 msec

図 5.2: 各階層への平均問合せ時間-グラフ-

(22)

5.5 考察

まず、コンテンツサーバとクライアントが同じマシンで行っているため、クライアントマシンからコンテンツサーバへ何ステップが必要なのか考えてみたい。全ての問合せの前にキャッシュを消去している。問合せに必要なステップは下の表5.2のようになる。

表 5.2: 実ステップ数と本来ステップ数の差 0層 1層 2層 3層実ステップ数 1 2 0 1 本来ステップ数 1 2 3 4 不足ステップ数 0 0 3 3

この表5.2と図5.2から、1ステップにかかる問合せ時間は1700msec程度であると考えられる。

この実験を繰り返したところ、同様の結果が得られた。この実験から、階層化によって1階層増えるたびに1ステップ分の時間が増えていくと考察できる。この時、マシン負荷の分散方法としての階層化によって、問合せ時間が増加していることから、トレードオフを考える必要がある。

(23)

第 6 章

マシン負荷と階層化のトレードオフの考察

6.1 階層化による問合せ時間の一般化

第5章において考察したように、階層化するたびに1ステップ分の時間が加算されていく。そこで、1ステップ分の問合せ時間を計測し、階層化による問合せ時間の変化の一般化を行う。第 5章で行った実験を繰り返し行ったところ1ステップ分の問合せ時間は1500msec〜2000msecの間で推移していた。この数値を裏付けるために、下の図6.1の測定マシンでDNSにおける平均な問合せ時間を測定したところ、1434.735msecという結果が得られた。これは第5章での実験結果を考えても、マシンの性能とDNSsecによる処理時間分の遅延を考えると第5章での結果は妥当であると考えられる。それを元に階層化における問合せ時間の一般化を行った。その結果は下の図6.2の通りである。

図 6.1: 平均DNS問合せ時間の測定環境

(24)

第 6章マシン負荷と階層化のトレードオフの考察

図 6.2: 問合せ時間の一般化

6.2 IP 電話の接続品質

2.3節でも記述したように、ENUMはIP電話において利用される場合が多いと考えられる。

そこで、トレードオフを考察する指標として、IP電話の接続品質を考える。2003年2月に発表された総務省の「ＩＰネットワーク技術に関する研究会」報告書(案)においてはISDN接続品質ベースの値を基盤として目標値(Y.1530草案)が示されている。その目標値は下の表6.1の通りである。

表 6.1: 自動接続遅延時間

平均最高品質 ISDN接続品質ベース値 8000msec 11000msec

目標値(Y.1530草案) 7500msec 8450msec

ここでの自動接続遅延時間はENUMを用いたIP電話クライアントの場合であると、下の様に表せる。

ENUMによって相手のVoIPアドレスを得る時間

+ VoIP用アドレスを名前解決し相手に呼び出し音を通知させる時間

自動接続遅延時間

本論文では目標値(Y.1530草案)の7500msecを指標として用いることとする。

(25)

6.3 マシン負荷と階層化のトレードオフ

まず、接続品質の目標値(Y.1530草案)を図に重ねて表示してみると下の図となる。

図 6.3: 接続品質の目標値

この時VoIP接続に必要な名前解決の時間を6.1で行った平均DNS問合せ時間を用いて考慮すると、1層まではIP電話の接続品質の目標値(Y.1530草案)内であると言えるが、2層以上は目標値を越えてしまい十分な接続品質を満たすことができないと言える。

次に00. . . 99までのE.164番号を登録したマシンに第4章と同様のマシンから同数の網羅的検索を行った場合のCPU使用率は下の図のようになった。

図 6.4: 管理桁数によるCPU使用率の違い

(26)

図6.4からわかるとおり第4章の結果と比べると、CPU使用率が約2割下がり、マシン負荷の面で改善されていることが分かる。よって2階層による管理が、マシン負荷と問合せ時間が最もバランスのとれている状態であると言える。

(27)

第 7 章結論

7.1 まとめ

本論文では多数のE.164番号を一台のマシンで管理した場合の網羅的検索におけるマシン負荷とその負荷軽減策として考えられる階層化における問合せ時間の増加のトレードオフを考察した。第4章での実験で10000個のE.164番号を1台のマシンで管理した場合におけるCPU負荷率を測定し、多数のE.164番号を少数のマシンで管理した場合には網羅的検索によって大きな負荷が与えられるために危険であることを確認した。第5章での実験で階層化することによって問合せ時間が徐々に増加することを確認した。第6章でマシン負荷と問合せ時間についてのトレードオフを考察し、その結果10000個のE.164番号を管理する場合は2階層に分けて管理する方法が最もバランスの取れた方法であると分かった。

今後ENUMという技術が一般化され、IP電話やそれに伴う様々なサービスに利用され多くの個人情報がDNSとうオープンなデータベース上に存在する状況が考えられる。その時に個人情報採取の目的で網羅的検索が行われることは容易に想像できる。したがって、本論文におけるテーマは管理者にとって大きな問題となるはずであり、本論文での考察は大いに有意義に用いられるはずである。

7.2 今後の課題

商用的にE.164番号を管理することを考えると、本論文の実験で使用したマシンとは異なり、

DNSに特化したマシンを使用するはずなので、その時の問合せ時間が変化する可能性がある。

またそれに伴い、マシン負荷の面での数値も変化する可能性がある。

また、本論文で使用した名前解決ソフトbind9.3.0beta4はベータ版であり、動作が不安定な時が見受けられた。その点が改善されればより正確なデータが取れると考えられる。

(28)

第 7 章結論

本論文におけるトレードオフの指標として実際の利用シーンで最も多く利用されることが予想されるIP電話の接続品質を用いたが、実際に利用されるのは表2.1にあるようにIP電話だけではない。今後、他サービスも利用されていく上で、他サービスを含めた統一的な指標の選定が必要になってくる可能性がある。

(29)

謝辞

本論文の作成にあたり、日頃より多大なるご指導を頂いております早稲田大学理工学部の後藤滋樹教授に深く感謝いたします。また、研究を進めるにあたって、有益なご意見、ご助言を頂いたパナソニックコミュニケーションズ株式会社瀬川卓見氏、多田謙太郎氏に感謝いたします。そして、ENUM班の一員としてともに研究を進めた杉田隆俊氏、舘直芳氏、山田大輔氏、横澤一岐氏、日頃より様々な助言をしていただいている後藤研究室の皆様に感謝いたします。最後に、

大きな精神的支えとなってくれた、あの部屋に集った仲間たち、石井勇弥氏、河野真也氏、関宏規氏に感謝いたします。

(30)

参考文献

[1] W.Richard Stevens著,橘康雄訳,井上尚司監訳: 『詳解TCP/IP VoL.1』,ピアソン・エジュケーション, 2000.

[2] W.Richard Stevens著,橘康雄訳,井上尚司監訳: 『詳解TCP/IP VoL.2』,ピアソン・エジュケーション, 2000.

[3] 福田祟男「IP電話もIMも,電話番号が代表アドレス」: 『日経Internet Solutions』 11月号,日経BP社, 2003

[4] 千村保文,村田利文監修: 『SIP教科書』,IDGジャパン, 2003 [5] 総務省: 『情報通信白書平成16年度版』,

http://www.johotsusintokei.soumu.go.jp/whitepaper/ja/cover/index.htm [6] 総務省: 『IPネットワーク技術に関する研究会報告書（案）』,

http://www.soumu.go.jp/s-news/2001/011226_3_a.html

[7] ENUMトライアルジャパン: 『ENUMトライアルジャパン第一次報告書』,

http://etjp.jp/about/activity/20040512/ETJPreport0512.pdf

[8] ENUMトライアルジャパン: 『ENUMトライアルジャパン第二次報告書』,

http://etjp.jp/about/activity/20041111/ETJP_2nd_report1111.pdf [9] JPRS:『DNSSECテストヘッド(e.164.jp配下)参加マニュアル』,

http://etjp.jp/about/wg/dnssec/e164.jp-manual.pdf

[10] 鶴長鎮一:『連載実用BIND9で作るDNSサーバ第13回次世代のセキュリティ拡張 DNSSECをBIND 9で実現』,

http://www.atmarkit.co.jp/flinux/rensai/bind913/bind913a.html [11] D. Eastlake: Domain Name System Security Extensions , RFC2535, 1999 [12] P. Faltstrom: E.164 number and DNS , RFC2916, 2000

(31)

参考文献

[13] O. Gudmundsson: Delegation Signer (DS) Resource Record (RR) , RFC3658, 2003 [14] P. Faltstrom, M. Mealling: The E.164 to Uniform Resource Identifiers (URI) ,

RFC3761, 2004

[15] R. Arends, R. Austein, M. Larson, D. Massey, S. Rose: DNSSEC Introduction and Requirements , draft-ietf-dnsext-dnssec-intro-08, 2003

[16] 杉田隆俊: 『ENUMを応用した三者間の通信法』,早稲田大学理工学部2003年度卒業論文, 2004

[17] 中崎雄祐: 『プライバシーを考慮したENUMシステムの提案と実装』, 早稲田大学理工学部 2003年度修士論文, 2004

[18] FreeBSD.org, ”FreeBSD Hyper Text Man Pages, ” http://www.freebsd.org/cgi/man.cgi

ENUM における DNSsec 問合せの解析

2004 年度 卒業論文