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

自律分散協調システム論第10回「DNS (Domain Name System)」中村　修 osamu@sfc.wide.ad.jp

今日の概要 • DNS • DNSとは？ • DNSに対する要求 • 名前空間の委譲 • キャッシュの利用 • サーバの分散 • DNSの応用 • ENUM • 自律分散システムとセキュリティ • dnssec

DNSとは？ • 名前解決機構: ホスト名とIPアドレスの対応を解決 • ホスト名 : 人間に分かりやすい計算機の識別子 • IPアドレス : IPにおける通信ノードの識別子 • 世界中の計算機のIPアドレスと名前の対応を管理する大規模分散データベースといわれる • 自律分散協調して動作するものの代名詞だが… ホスト名 IPアドレス www.sfc.keio.ac.jp133.27.4.127

ブラウザではhttp://www.sfc.keio.ac.jp/と入力 実はホスト名⇔IPアドレスの変換が行われているユーザネームサーバ身近な例：SFCのWebサーバを見る時 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.jp 133.27.1.100 host.sfc.keio.ac.jp 133.27.2.100 ※実際のネットワーク構成とは関係ありません

要求事項の整理 • DNSとは、 • 7億のエントリを持つ、 • 7億のホストから参照され、 • 頻繁に更新されるデータベースであり、 • かつ、インターネットにとって必要不可欠なので、絶対に止めてはいけない

管理権限委譲による自律分散化 各サーバは自律動作各サーバは上位（親）と下位（子）のみを知っている他のサーバの変化は関知しない祖父や孫は知らない全体のつながりも当然知らないキャッシュによる効率化ルートDNSサーバの分散化協調して動作する複数のルートDNSサーバを有効に選択する解決策: 自律分散協調を導入

ドメイン名の構造 • 住所のように情報を階層化して、扱う • 一単語では重複が発生する • 名前空間を分割することで委譲を可能にする(後述) 下位上位 www . sfc . keio . ac . jp 慶應義塾大学学術 wwwサーバ湘南藤沢　　キャンパス日本欧米の住所は、日本とは逆に細かい情報から先（左）に書く日本風に言うと、「日本の学術機関の慶應義塾大学の湘南藤沢キャンパスのwwwサーバ」

階層的な名前空間 例：www.sfc.keio.ac.jp ドメインツリー Root Domain ・ ccTLD gTLD …… jp uk net com SLD cnn ad ac co or … wide keio … u-tokyo TLD: Top Level DomaingTLD: generic TLDccTLD: Country Code TLDSLD: Second Level Domain sfc cc www.sfc.keio.ac.jp

管理権限の委譲 • 自分より下位（左）の管理権限を委譲する • 委譲している情報を聞くと、委譲した先のサーバを教えてくれる • 例：慶應義塾大学は、SFCの名前空間管理をSFCに委譲 • 上位は下位の情報に関して関知しない • 例：SFCのwwwサーバのアドレスを変更しても慶應義塾大学のサーバは関知しない www.sfc.keio.ac.jpのアドレスは？慶應義塾のサーバそれは「ＳＦＣのサーバ」が知ってるよ sfc.keio.ac.jpを委譲ＳＦＣのサーバ

7億個のデータが含まれる名前分割する ひとつのサーバが担当する量を減らしているこれで更新頻度の問題は解決できたが・・・・移譲された名前空間 Root Domain ・ ccTLD iTLD …… jp uk edu com SLD cnn ad ac co or … wide keio … u-tokyo sfc cc www.sfc.keio.ac.jp 委譲と更新頻度

Root Domain ・ ccTLD iTLD …… jp uk edu com SLD cnn ad ac co or … wide keio … u-tokyo sfc cc www.sfc.keio.ac.jp 名前解決の流れ : Rootへのアクセスの集中問い合わせ側 www.sfc.keio.ac.jpを問い合わせ Rootのサーバ左右の図を見ると、かならずRootを通ることがわかる！ Rootは7億のアクセスを捌く？ jpのサーバを返答 www.sfc.keio.ac.jpを問い合わせ Jpのサーバ ac.jpのサーバを返答 www.sfc.keio.ac.jpを問い合わせ ac.jpのサーバ keio.ac.jpのサーバを返答 www.sfc.keio.ac.jpを問い合わせ keio.ac.jp のサーバ sfc.keio.ac.jpのサーバを返答 www.sfc.keio.ac.jpを問い合わせ sfc.keio.ac.jp のサーバ www.sfc.keio.ac.jpのアドレスを返答

ＤＮＳとキャッシュ • キャッシュ: • 問い合わせに対して返答があった場合、その答えを一定期間保持する • 同じ名前に関しては問い合わせを出さない • リゾルバサーバ(キャッシュサーバ)の利用 • クライアントからの要求を受け、問い合わせを出すサーバ • キャッシュを多くのホストで共有し、効率化 • 効果 • Rootの近く(jpやcomなど)では再利用性が高い • 問い合わせを Root に出すことはほとんど無くなる

リゾルバサーバの動作(1) • DNSへの問い合わせの段階で、キャッシュを保存しておく　　リゾルバ　　サーバ www.sfc.keio.ac.jpを問い合わせ root ネームサーバ jpのネームサーバを返答 www.sfc.keio.ac.jpを問い合わせ www.sfc.keio.ac.jpを問い合わせ jp ネームサーバ ac.jpのネームサーバを返答クライアント www.sfc.keio.ac.jpを問い合わせ ac.jp ネームサーバ keio.ac.jpのネームサーバを返答 www.sfc.keio.ac.jpを問い合わせ keio.ac.jp ネームサーバ sfc.keio.ac.jpのネームサーバを返答 www.sfc.keio.ac.jpを問い合わせ www.sfc.keio.ac.jpのアドレスを返答 sfc.keio.ac.jp ネームサーバ www.sfc.keio.ac.jpのアドレスを返答

一旦名前を引けば、 同じ名前に関しては、外に問い合わせを出さずに返答する　　リゾルバ　　サーバ root ネームサーバ www.sfc.keio.ac.jpを問い合わせ jpのネームサーバを返答 www.sfc.keio.ac.jpを問い合わせ jp ネームサーバ www.sfc.keio.ac.jpを問い合わせ ac.jpのネームサーバを返答クライアント ac.jp ネームサーバ www.sfc.keio.ac.jpを問い合わせ keio.ac.jpのネームサーバを返答 keio.ac.jp ネームサーバ www.sfc.keio.ac.jpを問い合わせ www.sfc.keio.ac.jpなら知ってる！ sfc.keio.ac.jpのネームサーバを返答 sfc.keio.ac.jp ネームサーバ www.sfc.keio.ac.jpのアドレスを返答 www.sfc.keio.ac.jpを問い合わせ www.sfc.keio.ac.jpのアドレスを返答　　リゾルバ　　サーバ www.sfc.keio.ac.jpを問い合わせクライアント www.sfc.keio.ac.jpのアドレスを返答リゾルバサーバの動作(2)

名前解決の過程で問い合わせたサーバは記録しているので、名前解決の過程で問い合わせたサーバは記録しているので、違う名前を問い合わせでも、必要最低限の相手にしか問い合わせを出さないリゾルバサーバの動作(3) mail.sfc.keio.ac.jpのことは知らない。でも、sfc.keio.ac.jpをどのサーバが管理してるかは知ってるぞ！　　リゾルバ　　サーバ root ネームサーバ www.sfc.keio.ac.jpを問い合わせ jpのネームサーバを返答 www.sfc.keio.ac.jpを問い合わせ jp ネームサーバ www.sfc.keio.ac.jpを問い合わせ mail.sfc.keio.ac.jpを問い合わせ　　リゾルバ　　サーバ ac.jpのネームサーバを返答クライアント ac.jp ネームサーバ mail.sfc.keio.ac.jpを問い合わせ www.sfc.keio.ac.jpを問い合わせ keio.ac.jpのネームサーバを返答クライアント keio.ac.jp ネームサーバ www.sfc.keio.ac.jpを問い合わせ sfc.keio.ac.jp ネームサーバ sfc.keio.ac.jpのネームサーバを返答 sfc.keio.ac.jp ネームサーバ www.sfc.keio.ac.jpのアドレスを返答 www.sfc.keio.ac.jpを問い合わせ mail.sfc.keio.ac.jpのアドレスを返答 mail.sfc.keio.ac.jpのアドレスを返答 www.sfc.keio.ac.jpのアドレスを返答

変化が世界に早く伝播する 問い合わせを受ける量が増える変化が伝播するのが遅い問い合わせを受ける量が減る短いキャッシュ有効期限長いキャッシュと有効期限(TTL) • キャッシュに有効期限を設けて、その時間が経過したらキャッシュを破棄する • データを変更しても、キャッシュの有効期限の間は古いデータを参照される可能性がある • 効率と整合性はトレードオフ • 有効期限の設定:根元は長く、末端は短く

耐故障性 • インターネットのサービスはDNSに依存 • wwwを見るのにも(URL) • メールを出すのにも(メールアドレス) • 根元に近いところが落ちると？ • それ以下の名前が検索できなくなる

サーバの分散化 • ひとつのゾーンに関して、複数のサーバで管理 • 上位はそれらすべてに関して情報を持つ • サーバ１が不調の場合でも・・・ • サーバ２かサーバ３に聞けば分かる • １が使えなかった場合は２か３に聞く www.sfc.keio.ac.jpのアドレスは？慶應義塾のサーバそれは「ＳＦＣのサーバ１」と「ＳＦＣのサーバ２」と「ＳＦＣのサーバ３」が知ってるよ sfc.keio.ac.jpを委譲ＳＦＣのサーバ１ＳＦＣのサーバ２ＳＦＣのサーバ３

ルートネームサーバの分散 • ルートネームサーバ • TLDの情報を管理するサーバ • 理論上、すべての問い合わせは最初にルートネームサーバに来る • 名前解決を行うためには、ローカルネームサーバからルートへの接続性が必要 • ルートサーバの分散 • 地理的、ネットワーク的に分散している • どれか１つが落ちたとしても他に回る • 2000年問題などの致命的な問題（の可能性）があった場合も対処可能

Root ・ ccTLD iTLD …… jp uk edu com SLD cnn ad ac co or … wide keio … u-tokyo sfc cc www.sfc.keio.ac.jp ルートサーバの発見:　ヒントファイルの存在 ; 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 リゾルバサーバは同じヒントファイルを使用

DNS Root Server I-NORDUnet: Stockholm, other 28sites E-NASA: Mt View F-ISC: Palo Alto, other 39sites J-VeriSign: Mt View M-WIDE: Tokyo, Seoul, Paris, SanFrancisco B-ISI: Marina Del Rey L-EPB: Marina Del Rey K-Ripe: London, other 17sites A-Verisign: Dulles C-Cogent: Herndon, NY, LosAngeles, Chicago D-UMD: College Park G-DNIC Network: Columbus H-ARL: Aberdeen

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

10 7+3x Y = log(0.98 * ) ルートネームサーバの選択 • ローカルネームサーバは、１３個のサーバを入れ替わり使う • 応答にかかった時間が短いサーバを優先的に使い、結果的に効率の良いサーバを頻繁に使うことになる • 選択確率（BINDでの実装) • 使用頻度をy、平均応答時間をxとすると、 • 測定した結果、日本の場合約６割強の問い合わせが1つのサーバに寄せられる平均7.7%

DNSサーバのAnycast化への契機 • DNSサーバへのDDoS攻撃 • 2002年10月22日 • ICMPリクエストの大量送出による • ISCのDNSサーバでは一時的に80Mbpsまでトラフィックが増加 • 13のルートサーバのうち動作を続けたのは4つ • この攻撃によるDNS機能への影響はなかった • 長時間の攻撃が続いたとすると状況は分からなかった

203.178.138.99 www.soi.wide.ad.jp Anycast • IPv6から提供されているアドレス割当手法 • Anycastを利用しない場合 • IPアドレス＝一意のホストという関係 • Anycastを利用する場合 • IPアドレス＝一意のサービスという関係 203.178.138.99 www.soi.wide.ad.jp(CA) www.soi.wide.ad.jp(JP) www.soi.wide.ad.jp(US) 同じサービスを提供しているホスト

RFC3258に定義 独立した専用の AS および IP アドレスブロックを複数の拠点から BGP 的に広報同一の IP アドレスを多拠点からサービスすることを可能とする BGPの経路選択によって「最も近い」サーバを選択ただし必ずしも最も近いとは限らない BGP Anycast AS-F AS-A AS-B AS-C AS-D AS-E AS-F

Anycast Solution San Jose London 192.168.100.0/24 192.168.101.0/24 192.168.102.0/24 Hong Kong 192.168.100.0/24 192.168.101.0/24 192.168.102.0/24 192.168.100.0/24 192.168.101.0/24 192.168.102.0/24 ISP Hong Kong San Jose London

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 I-NORDUnet: Stockholm, other 28sites E-NASA: Mt View F-ISC: Palo Alto, other 39sites J-VeriSign: Mt View M-WIDE: Tokyo, Seoul, Paris, SanFrancisco B-ISI: Marina Del Rey L-EPB: Marina Del Rey K-Ripe: London, other 17sites A-Verisign: Dulles C-Cogent: Herndon, NY, LosAngeles, Chicago D-UMD: College Park G-DNIC Network: Columbus H-ARL: Aberdeen

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では親と子しかわからないので、自分のゾーンの公開鍵は親に署名してもらう • 最終的にクライアントはルートの公開鍵を持っていれば検証可能

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

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