自律分散協調システム論第 10 回「 DNS (Domain Name System) 」

自律分散協調システム論第 10回「 DNS (Domain Name System)」

中村　修[email protected]

今日の概要• DNS

– DNSとは？– DNSに対する要求–名前空間の委譲–キャッシュの利用–サーバの分散

• DNSの応用– ENUM

• 自律分散システムとセキュリティ– dnssec

DNSとは？• 名前解決機構 : ホスト名と IPアドレスの対応を解決

–ホスト名 : 人間に分かりやすい計算機の識別子– IPアドレス : IPにおける通信ノードの識別子

• 世界中の計算機の IPアドレスと名前の対応を管理する大規模分散データベースといわれる

• 自律分散協調して動作するものの代名詞だが…

www.sfc.keio.ac.jp 　　　 133.27.4.127ホスト名 IPアドレス

http://www.sfc.keio.ac.jp/

身近な例： SFCのWebサーバを見る時• ブラウザでは http://

www.sfc.keio.ac.jp/と入力

• 実はホスト名⇔ IPアドレスの変換が行われている

ユーザ

ネームサーバ

www.sfc.keio.ac.jpが見たいんだけど…

133.27.4.127のサーバにアクセスしてください

WEBサーバ133.27.4.127

DNSへの要求 (1/3) エントリは？• 世界中のホストは調べられるだけでも約 7億５千万

• この数だけエントリを持たねばならない

DNSへの要求 (2/3) サービスの提供は ?• サービスを提供する対象も多い！

–世界中のホスト（ 7.5億）だけではない– NATの裏側とか、本当はもっと多い–世界に向けて潤沢な回線ももちろん必要

ＤＢ

DNSへの要求 (3/3) 更新頻度• IPアドレスが変わるとデータベースを更新

–配置換え・構成変更・引越し

• ひとつのホストが１年に一度移動するとしても・・・７５０ ,０００ ,０００

３６５ｘ８６４００＝　　２３．７８ [更新／秒］

という更新頻度になる

Alpha館133.27.1.0/24

Iota館133.27.2.0/24

※実際のネットワーク構成とは関係ありません

host.sfc.keio.ac.jp133.27.1.100

host.sfc.keio.ac.jp133.27.2.100

要求事項の整理• DNSとは、

– 7億のエントリを持つ、– 7億のホストから参照され、–頻繁に更新されるデータベース

であり、

• かつ、インターネットにとって必要不可欠なので、絶対に止めてはいけない

解決策 : 自律分散協調を導入• 管理権限委譲による自律分散化

–各サーバは自律動作–各サーバは上位（親）と下位（子）のみを知っている

• 他のサーバの変化は関知しない• 祖父や孫は知らない• 全体のつながりも当然知らない

• キャッシュによる効率化• ルート DNSサーバの分散化

–協調して動作する複数のルート DNSサーバを有効に選択する

ドメイン名の構造• 住所のように情報を階層化して、扱う

–一単語では重複が発生する–名前空間を分割することで委譲を可能にする ( 後

述 )www . sfc . keio . ac . jp

欧米の住所は、日本とは逆に細かい情報から先（左）に書く日本風に言うと、

「日本の学術機関の慶應義塾大学の湘南藤沢キャンパスの wwwサーバ」

日本学術

慶應義塾大学

湘南藤沢

　　

キャンパ

スww

w

サー

バ

上位下位

ドメインツリー

• 階層的な名前空間– 例： www.sfc.keio.ac.jp jp netuk

・

or ad coac

……

…

…

ccTLD

sfc

u-tokyokeio

SLD

cnn

com

Root Domain

www.sfc.keio.ac.jp

cc

wide

gTLD

TLD: Top Level DomaingTLD: generic TLDccTLD: Country Code TLDSLD: Second Level Domain


管理権限の委譲• 自分より下位（左）の管理権限を委譲する

– 委譲している情報を聞くと、委譲した先のサーバを教えてくれる– 例：慶應義塾大学は、 SFCの名前空間管理を SFCに委譲

• 上位は下位の情報に関して関知しない– 例： SFCの wwwサーバのアドレスを変更しても

慶應義塾大学のサーバは関知しない

慶應義塾のサーバ

ＳＦＣのサーバ

www.sfc.keio.ac.jp のアドレスは？

それは「ＳＦＣのサーバ」が知ってるよsfc.keio.ac.jpを委譲


委譲と更新頻度• 7億個のデータが含まれる名前分割する

• ひとつのサーバが担当する量を減らしている

• これで更新頻度の問題は解決できたが・・・・

移譲された名前空間

jp eduuk

・

or ad coac

……

…

…

ccTLD

sfc

u-tokyokeio

SLD

cnn

com

Root Domain

www.sfc.keio.ac.jp

cc

wide

iTLD

名前解決の流れ : Rootへのアクセスの集中

Rootのサーバ

Jpのサーバ

ac.jpのサーバ

keio.ac.jpのサーバ

sfc.keio.ac.jpのサーバ

　　問い合わせ側

www.sfc.keio.ac.jpを問い合わせ





jpのサーバを返答

ac.jpのサーバを返答

keio.ac.jpのサーバを返答

sfc.keio.ac.jpのサーバを返答

www.sfc.keio.ac.jpのアドレスを返答

jp eduuk

・

or ad coac

……

…

…

ccTLD

sfc

u-tokyokeio

SLD cnn

com

Root Domain

www.sfc.keio.ac.jp

cc

wide

iTLD

左右の図を見ると、かならず Rootを通ることがわかる！

Rootは 7億のアクセスを捌く？

ＤＮＳとキャッシュ• キャッシュ :

– 問い合わせに対して返答があった場合、その答えを一定期間保持する

– 同じ名前に関しては問い合わせを出さない

• リゾルバサーバ (キャッシュサーバ )の利用– クライアントからの要求を受け、問い合わせを出すサーバ– キャッシュを多くのホストで共有し、効率化

• 効果– Rootの近く (jpや comなど )では再利用性が高い– 問い合わせを Root に出すことはほとんど無くなる

リゾルバサーバの動作 (1)• DNSへの問い合わせの段階で、キャッシュを保存しておく

rootネームサーバ

jpネームサーバ

ac.jpネームサーバ

keio.ac.jpネームサーバ

sfc.keio.ac.jpネームサーバ

　　リゾルバ　　サーバクライアント






jpのネームサーバを返答

ac.jpのネームサーバを返答

keio.ac.jpのネームサーバを返答

sfc.keio.ac.jpのネームサーバを返答




リゾルバサーバの動作 (2)• 一旦名前を引けば、 • 同じ名前に関しては、外

に問い合わせを出さずに返答する






















www.sfc.keio.ac.jpなら知ってる！


リゾルバサーバの動作 (3)• 名前解決の過程で問い合わせたサーバは記録しているので、

• 違う名前を問い合わせでも、必要最低限の相手にしか問い合わせを出さない



















　　リゾルバ　　サーバクライアントsfc.keio.ac.jp

ネームサーバ

mail.sfc.keio.ac.jpのことは知らない。でも、 sfc.keio.ac.jpをどのサーバが管理してるかは知ってるぞ！

mail.sfc.keio.ac.jpを問い合わせ

mail.sfc.keio.ac.jpのアドレスを返答

mail.sfc.keio.ac.jpを問い合わせ

mail.sfc.keio.ac.jpのアドレスを返答

キャッシュと有効期限 (TTL)• キャッシュに有効期限を設けて、その時間が

経過したらキャッシュを破棄する• データを変更しても、キャッシュの有効期限の間は古いデータを参照される可能性がある

• 効率と整合性はトレードオフ• 有効期限の設定 : 根元は長く、末端は短く

短い長いキャッシュ有効期限

変化が世界に早く伝播する問い合わせを受ける量が増える

変化が伝播するのが遅い問い合わせを受ける量が減る

耐故障性• インターネットのサービスは DNSに依存

– wwwを見るのにも (URL)–メールを出すのにも (メールアドレス )

• 根元に近いところが落ちると？– それ以下の名前が検索できなくなる

サーバの分散化• ひとつのゾーンに関して、複数のサーバで管理

• 上位はそれらすべてに関して情報を持つ• サーバ１が不調の場合でも・・・

–サーバ２かサーバ３に聞けば分かる–１が使えなかった場合は２か３に聞く

慶應義塾のサーバ

ＳＦＣのサーバ１

www.sfc.keio.ac.jp のアドレスは？

それは「ＳＦＣのサーバ１」と「ＳＦＣのサーバ２」と「ＳＦＣのサーバ３」が知ってるよ

sfc.keio.ac.jpを委譲

ＳＦＣのサーバ２ＳＦＣのサーバ３


ルートネームサーバの分散• ルートネームサーバ

– TLDの情報を管理するサーバ– 理論上、すべての問い合わせは最初にルートネームサーバに来る

– 名前解決を行うためには、ローカルネームサーバからルートへの接続性が必要

• ルートサーバの分散– 地理的、ネットワーク的に分散している– どれか１つが落ちたとしても他に回る– 2000年問題などの致命的な問題（の可能性）があった場合も対処可能

ルートサーバの発見 :　ヒントファイルの存在; This file holds the information on root name servers needed to; initialize cache of Internet domain name servers; (e.g. reference this file in the "cache . <file>"; configuration file of BIND domain name servers).;; This file is made available by InterNIC ; under anonymous FTP as; file /domain/named.root; on server FTP.INTERNIC.NET;; last update: Nov 5, 2002; related version of root zone: 2002110501;;; formerly NS.INTERNIC.NET;. 3600000 IN NS A.ROOT-SERVERS.NET.A.ROOT-SERVERS.NET. 3600000 A 198.41.0.4;; formerly NS1.ISI.EDU;. 3600000 NS B.ROOT-SERVERS.NET.B.ROOT-SERVERS.NET. 3600000 A 128.9.0.107;; formerly C.PSI.NET;. 3600000 NS C.ROOT-SERVERS.NET.;; housed in Japan, operated by WIDE;. 3600000 NS M.ROOT-SERVERS.NET.M.ROOT-SERVERS.NET. 3600000 A 202.12.27.33; End of File

jp eduuk

・

or ad coac

……

…

…

ccTLD

sfc

u-tokyokeio

SLD cnn

com

Root

www.sfc.keio.ac.jp

cc

wide

iTLD

リゾルバサーバは同じヒントファイルを使用

DNS Root Server

M-WIDE: Tokyo, Seoul, Paris, SanFrancisco

K-Ripe: London, other 17sites

I-NORDUnet: Stockholm, other 28sites

A-Verisign: DullesC-Cogent: Herndon, NY, LosAngeles, ChicagoD-UMD: College ParkG-DNIC Network: ColumbusH-ARL: Aberdeen

B-ISI: Marina Del ReyL-EPB: Marina Del Rey

E-NASA: Mt ViewF-ISC: Palo Alto, other 39sitesJ-VeriSign: Mt View

ルートネームサーバの運用基準RFC2780(Root Name Server Operational Requirements)1. ネームサーバは BINDを使用する2. UDP チェックサムを使う3. 専用ホストであること（他のサービスをしていない） 4. 相互に時刻同期を行う5. もっとも“ 良い”インターフェースのアドレスを広告する6. 安全な場所（出入りが厳重に管理されている場所）に配置する7. 安全なネットワーク上に配置する8. 平均 CPU時間は最大値の３分の１以下でなければいけない9. 障害報告のメールに 24時間以内に応答する10.問い合わせが障害を引き起こすものでない限り、あらゆるホストからの

問い合わせを受け付ける11.AXFRに応答してはいけない12.再起的な問い合わせは行わない13.アナウンスは変更を行う１２時間前に行う14.将来的に、ルートゾーンの署名を行う15.Etc…..

ルートネームサーバの選択• ローカルネームサーバは、１３個のサーバを入れ替わり

使う• 応答にかかった時間が短いサーバを優先的に使い、結果

的に効率の良いサーバを頻繁に使うことになる• 選択確率（ BINDでの実装 )

– 使用頻度を y、平均応答時間を xとすると、

– 測定した結果、日本の場合約６割強の問い合わせが 1つのサーバに寄せられる

Y = log(0.98 * )107+3x

平均 7.7%

DNSサーバの Anycast化への契機• DNSサーバへの DDoS 攻撃

– 2002年 10 月 22日– ICMPリクエストの大量送出による– ISCの DNSサーバでは一時的に 80Mbpsまでトラ

フィックが増加

• 13のルートサーバのうち動作を続けたのは 4つ

• この攻撃による DNS機能への影響はなかった– 長時間の攻撃が続いたとすると状況は分からなかった

Anycast• IPv6から提供されているアドレス割当手法

– Anycastを利用しない場合• IPアドレス＝一意のホストという関係

– Anycastを利用する場合• IPアドレス＝一意のサービスという関係

203.178.138.99

www.soi.wide.ad.jp

203.178.138.99

www.soi.wide.ad.jp(US)

www.soi.wide.ad.jp(JP) www.soi.wide.ad.jp(CA)

同じサービスを提供しているホスト

BGP Anycast• RFC3258に定義

– 独立した専用の AS および IP アドレスブロックを複数の拠点から BGP 的に広報

– 同一の IP アドレスを多拠点からサービスすることを可能とする

• BGPの経路選択によって「最も近い」サーバを選択

• ただし必ずしも最も近いとは限らない

AS-D

AS-E

AS-C

AS-AAS-B

AS-F

AS-F

Anycast Solution

London

192.168.100.0/24192.168.101.0/24192.168.102.0/24

ISP

Hong KongLondon

San Jose

Hong Kong

San Jose

192.168.100.0/24192.168.101.0/24192.168.102.0/24

192.168.100.0/24192.168.101.0/24192.168.102.0/24

Anycast化のポイント• メリット

– DNSサーバ複製によりサーバ最大数に縛りがなくなる

– 地理的な問題が解決される–可用性の向上– DoS 対策– 独立することによるポータビリティの確保など

• デメリット–ネットワーク管理の煩雑化– 監視の問題　など

Reference: http://jprs.jp/tech/jp-dns-info/2003-07-10-jp-dns-operation.html

Anycastの実装（２００ホスト）• B:LAX, D:CGS, E:NUQ, H:APG A:LAX,NYC,KPAO,IAD

C:IAD,LAX,CHI,NYC,FRA,MAD F:YOW,KPAO,SJC,NYC,SFO,MAD,HKG,LAX,ROM,AKL,SAO,PEK,SEL F:MOW,TPE,DXB,PAR,SIN,BNE,YTO,MRY,LIS,JNB,TLV,JKT,MUC,OSA F:PRA,AMS,BCN,NBO,MAA,LON,SCL,DAC,KHI,TRN,CHI,BUE,CCS,OSL F:PTY,UIO,KUL,SUV,CAI,ATL,TGD,SXM G:CMH,SAT,HNL,OKO,STR,NAP I:STO,HEL,MIL,LON,GVA,AMS,OSL,BKK,HKG,BRU,FRA,ANK,BBU,CHI I:WAS,TYO,KUL,KPAO,JKL,WLG,JNB,PER,SFO,NYC,SIN,MIA,IAD,BOM I:PEK,MNL,DOH,CMB,VIE,PAR,TPE J:IAD(2),MIA,ATL,SEA,CHI,NYC,LAX,NUQ,SFO,AMS,LON,ARN,TYO J:SEL,PEK,SIN,DUB,KUN,NBO,YUL,SYD,CAI,WAW,BSB,SOF,PRG,JNB J:YTO,BUE,MAD,BRN,HKG(2),TRN,BOM,OSL,BRU,PAR(2),HEL,FRA,RIX J:MIL,ROM,LIS,SJU,EDI,TLL,TPE,NYC,KPAO,ANC,MOW,MML,KUL,LUX J:GUM,YVR,WLG K:LON,AMS,FRA,ATH,DOH,MIL,RKV,HEL,GVA,POZ,BUD,AUH,TYO,BNE K:MIA,DEL,OVB,DARL:LAX,MIA,PRG M:TYO(3),SEL,PAR,SFO

DNS Root Server

M-WIDE: Tokyo, Seoul, Paris, SanFrancisco

K-Ripe: London, other 17sites

I-NORDUnet: Stockholm, other 28sites

A-Verisign: DullesC-Cogent: Herndon, NY, LosAngeles, ChicagoD-UMD: College ParkG-DNIC Network: ColumbusH-ARL: Aberdeen

B-ISI: Marina Del ReyL-EPB: Marina Del Rey

E-NASA: Mt ViewF-ISC: Palo Alto, other 39sitesJ-VeriSign: Mt View

ROOTZONEの変更権限は誰がやるか• DNS／ドメインツリーは開かれたシステム

–いつ何時、誰でも参加することが可能–自律分散的なシステムによる柔軟な拡張性が可能にしている

• 責任は、結局、 ICANNとアメリカ政府が管理– gTLD(Generic Top Level Domain)

• .com .net .org 等• Verisignが運用

– ccTLD(Country Code Top Level Domain)• .jp .to .uk 等• 地域ドメインレジストリが運用

– JPRS(JaPan Registry Service)

ドメインの取得• 取得申請を出せば誰でも使えます

– ccTLD• .jp• 他の国もそこの policy が許すなら

– .to / .ac / .tv

– gTLD• .com / .net / .org

分散システムとセキュリティ： DNSと詐称• 詐称

– 正当な通信相手に代わって通信を行なう–例： webサーバの通信を詐称して、パスワードやクレジットカード番号などを不正に入手

• DNSにも詐称などの危険性はある– UDPによる通信 (TCPよりやられやすい )

DNS 詐称の例• クライアントとサーバ間の通信

ネームサーバ

１．問い合わせクライアント

攻撃者（詐称者）

２．問い合わせより先に　　答えを返す

攻撃できるポイント• リゾルバサーバとクライアントの間

– ピンポイントでクライアントを狙える• ネームサーバとリゾルバサーバ間

–キャッシュされるので影響範囲が広い

リゾルバサーバネームサーバ

クライアント

詐称による脅威 (DNS)• 名前を詐称する　＝　あらゆる通信を不正に入手できる–インターネット上のほとんどの通信は、まずＤＮ

Ｓで名前を検索するところから始まる– 詐称によって正当な相手とは違う IPアドレスを通信相手にしてしまえる

脅威の例• Amazon.co.jp を詐称してログインアカウント・クレジットカード番号入手

• sfc.keio.ac.jp を詐称して、藤沢の学生に宛てたメールを入手

• Asahi.comを詐称して嘘のニュースを流す

自律分散協調システムとセキュリティ• データの正当性の保証

–この情報は本当に正しいのか？– 何をもって正しいと証明するのか

• 分散しているシステムでは難しい

初対面の相手をどうやって信用するか？• 現実社会を自律分散協調システムとして

– 相手は「私は＊＊＊のＸＸＸという者です」と言っている

–通常は身分証明書を使う• 学生証、免許証

• 証明書はどこが出すのか？

証明書• ある内容が正しいことを示す• 証明を行なう権威というものがある

–日本の身分証明書なら日本政府• 内容を変えるたびに更新が必要

– 学生証における進級・進学–自動車免許証のオートマ限定解除

公開鍵暗号方式• それぞれ１回ずつ行なうと元に戻る不可逆演算をする– xφ= y, yφ’ = x ( 掛け算じゃないよ！ )– 剰余などを使う– それぞれの逆演算は難しい

• xが元の情報、 y が暗号化された情報• Φおよび φ’がそれぞれ鍵

公開鍵暗号方式の使い方 (1)• 不特定多数からの暗号化した受け取り

–例えばメールなど– φを公開鍵、 φ’を秘密鍵とする– φは一般に公開して、他の人はそれを使って暗号化 (xφ = y)

– φ’は自分だけが持っておく–自分しか暗号化した内容を戻せない (yφ’ = x)

公開鍵暗号の使い方 (2)• 自分が書いたことの証明（署名）

– 同じく φを公開鍵、 φ’を秘密鍵– 書いた内容を φ’で暗号化 (xφ’=y)– 平文と暗号化した内容を一緒に送る

• つまり、 x と y を送る• この場合、 y のことを「（電子）署名」という

–他の人は公開鍵 φでその内容を検証できる• 署名を複合化して（ yφ＝ x）、一緒に送られてきた x と等しいか検証

鶏と卵• 公開鍵が正しいことをどうやって証明する？

– 公開鍵で・・・・・• 最終的には、信用できる手段で公開鍵を手に入れることが必要–ネットワーク以外の方法

• 書籍、 CD-ROM、新聞、人から聞く、などなど• IEには最初からいくつかの公開鍵（証明書）が入っている

DNSのセキュリティ (dnssec)• DNSのデータを署名し、クライアントが検証する– 誰が署名するか

• 例によって、たったひとつの秘密鍵で全部を署名することは不可能

自律分散的な署名• それぞれのゾーンが公開鍵と秘密鍵（鍵対）を持つ• それぞれの公開鍵はゾーンが配布

– DNSのレコードとして取得可能• その公開鍵を他の秘密鍵で署名

– DNSでは親と子しかわからないので、自分のゾーンの公開鍵は親に署名してもらう

• 最終的にクライアントはルートの公開鍵を持っていれば検証可能

検証の流れ

Jp

ac.jp

keio.ac.jp

sfc.keio.ac.jp

　　検証側

Rootの証明書で jpの証明書を検証

jpの証明書で ac.jpの証明書を検証

ac.jpの証明書で keio.ac.jpの証明書を検証

keio.ac.jpの証明書で sfc.keio.ac.jpの証明書を検証

最後に、得たデータを sfc.keio.ac.jpの証明書で検証

DNSSECのデメリット• データが膨大になる

– 鍵と署名のデータ– もともといっぱいいっぱいのところに入れるのは大変

(Root など )• 手順が面倒

– 更新のたびに署名が必要– 鍵を変更するたびに親に再署名してもらう

• jp や com などの負担は高い• データの鍵と鍵を署名する鍵を別にすることである程度対処可能

• 親との結びつきが強くなって、自律性が薄くなる

DNSSECの現状• 実はあまり使われていない

– Root/TLDではどこも使っていません– 各 TLDの Registry が試験的に行なっている程度

• dnssec.jp 等• ここを基点として公開鍵を発行

• 原因は？– デメリットが大きい– DNS 詐称による危険性があまり知られていない– そもそもメカニズムに問題があるのでは？

• 自律分散協調的な信用メカニズムが世界中で動いている例はまだない

Appendix

Anycast DNS

ルートネームサーバの選択• ローカルネームサーバは、１３個のサーバを入れ替わり

使う• 応答にかかった時間が短いサーバを優先的に使い、結果

的に効率の良いサーバを頻繁に使うことになる• 選択確率（ BINDでの実装 )

– 使用頻度を y、平均応答時間を xとすると、

– 測定した結果、日本の場合約６割強の問い合わせが 1つのサーバに寄せられる

Y = log(0.98 * )107+3x

平均 7.7%

DNSサーバの Anycast化への契機• DNSサーバへの DDoS 攻撃

– 2002年 10 月 22日– ICMPリクエストの大量送出による– ISCの DNSサーバでは一時的に 80Mbpsまでトラ

フィックが増加

• 13のルートサーバのうち動作を続けたのは 4つ

• この攻撃による DNS機能への影響はなかった– 長時間の攻撃が続いたとすると状況は分からなかった

Anycast• IPv6から提供されているアドレス割当手法

– Anycastを利用しない場合• IPアドレス＝一意のホストという関係

– Anycastを利用する場合• IPアドレス＝一意のサービスという関係

203.178.138.99

www.soi.wide.ad.jp

203.178.138.99

www.soi.wide.ad.jp(US)

www.soi.wide.ad.jp(JP) www.soi.wide.ad.jp(CA)

同じサービスを提供しているホスト

BGP Anycast• RFC3258に定義

– 独立した専用の AS および IP アドレスブロックを複数の拠点から BGP 的に広報

– 同一の IP アドレスを多拠点からサービスすることを可能とする

• BGPの経路選択によって「最も近い」サーバを選択

• ただし必ずしも最も近いとは限らない

AS-D

AS-E

AS-C

AS-AAS-B

AS-F

AS-F

Anycast Solution

London

192.168.100.0/24192.168.101.0/24192.168.102.0/24

ISP

Hong KongLondon

San Jose

Hong Kong

San Jose

192.168.100.0/24192.168.101.0/24192.168.102.0/24

192.168.100.0/24192.168.101.0/24192.168.102.0/24

Anycast化のポイント• メリット

– DNSサーバ複製によりサーバ最大数に縛りがなくなる

– 地理的な問題が解決される–可用性の向上– DoS 対策– 独立することによるポータビリティの確保など

• デメリット–ネットワーク管理の煩雑化– 監視の問題　など

Reference: http://jprs.jp/tech/jp-dns-info/2003-07-10-jp-dns-operation.html

DNSの応用 : ENUMとは• 電話番号からサービスを検索

– メールアドレス– Webページのアドレス– SIPアドレス– H.323– インターネット FAX　等

• 利用者は状況に応じてサービスを選択• 標準化

IETFと ITU-Tが共同で標準化を実施

ENUMの概要

電話網 GW

Internet

既存の機能

ENUM

電話網

SIPGW

FAXserver

httpserver

httpserver

GW

(1)問い合わせ

(2)利用可能なサービスを返答

(3)サービス　　の選択

(4)着信

DNS

VoIP 端末

ユーザ端末ユーザ端末

FAX

電話

電話

ENUMのドメイン名• 電話番号

– 0AB~J 番号を使用– cf.)03 – 1234 – 5678

• ENUMで用いられる番号– E.164 番号を使用– + 国番号 -0AB~J 番号– cf.)+81 – 3 – 1234 – 5678

• ENUMで用いられるドメイン名– DNSの逆引きのようドメイン名になる– cf.)8.7.6.5.4.3.2.1.3.1.8.e164.arpa

東京

日本

ENUMドメイン

E.164 番号からドメイン名の変換– E.164 番号

• +81-3-1234-5678– 先頭の＋をのぞいて数字以外の文字を削除

• +81312345678– 先頭の＋を削除

• 81312345678– 数字の間に「 .」をいれる

• 8.1.3.1.2.3.4.5.6.7.8– 順番を逆にする

• 8.7.6.5.4.3.2.1.3.1.8– .e１６４． aｒｐａを付加

• 8.7.6.5.4.3.2.1.3.1.8.e164.arpa

ENUMの現状• 技術的には実現しつつある

– ENUMトライアルジャパン ETJPの実証実験• 最小構成 ENUM DNSの構築は完了

• 実現へ向けての課題–プライバシー– DNSの肥大化と複雑化

ENUMの課題• プライバシーの問題

– DNSは公開 DB• だれでもアクセスできる

– SPAM業者などによる総当たり

• 網羅的に検索可能– 電話番号、メールアドレス、 SIPアドレスなど

• DNSの肥大化・複雑化–管理すべきエントリの肥大化・複雑化

• 日本の電話総数 1億 4千万台 (固定 /携帯 /PHS 含む )#1–管理の難しさとパフォーマンス

• 30分に１度は更新が必要 (携帯電話番号のDBは約 30分 )• 毎秒 5万件の問い合わせ

2000年問題時の推移

Documents

自律分散協調システム論 第 10 回「 DNS (Domain Name System) 」

自律分散協調システム論第 10 回「 DNS (Domain Name System) 」