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

自律分散協調システム論第11回「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) エントリは？ • 世界中のホストは調べられるだけでも約２億５千万 • この数だけエントリを持たねばならない

ＤＢ DNSへの要求(2/3) サービスの提供は? • サービスを提供する対象も多い！ • 世界中のホスト（2.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とは、 • 2億のエントリを持つ、 • 2億のホストから参照され、 • 頻繁に更新されるデータベースであり、 • かつ、インターネットにとって必要不可欠なので、絶対に止めてはいけない

管理権限委譲による自律分散化 各サーバは自律動作各サーバは上位（親）と下位（子）のみを知っている他のサーバの変化は関知しない祖父や孫は知らない全体のつながりも当然知らないキャッシュによる効率化ルート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を委譲ＳＦＣのサーバ

２億個のデータが含まれる名前分割する ひとつのサーバが担当する量を減らしているこれで更新頻度の問題は解決できたが・・・・移譲された名前空間 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は２億のアクセスを捌く？ 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

2000年問題時の推移

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)

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