20111029 part1-dnsをあえてdisってみる-事後資料

私は誰?• ⽒名: 森下泰宏（もりしたやすひろ） – 1965年9⽉21⽇⽣まれ（46歳）男性• 通称: オレンジさん – 理由は少し後で説明します – 呼ぶ時には苗字でも通称でも、お好きなほうでOKです• twitter ID: @OrangeMorishita• 現在の勤務先: – 株式会社⽇本レジストリサービス（JPRS）• 現在の肩書: 技術広報担当 Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 2

経歴、付き合いなど• ネットワークとの付き合い: 1986年から – 知⼈からもらった300ボーの⾳響カプラで⼈⽣変わりました• UNIXとの付き合い: 1988年から – 「最新UNIX」という本で⼈⽣変わりました – 最初に触ったUNIX: 4.2BSD – 最初に管理したサーバー: VAX-11/750• DNSとの付き合い: 1990年から – 最初に触ったBIND: 4.8.3• より詳しい経歴: http://森下泰宏.jp Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 3

最近のお仕事• いろいろ書く – 書籍「実践DNS」（共著） – JPRSトピックス＆コラム – JPRSメールマガジン「from JPRS」増刊号• いろいろお知らせする – 「重複をお許しください」• いろいろ広報・宣伝する – JPRS出展ブース（JANOG、Interopなど） – Internet Weekランチセミナー Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 4

なぜミドルネームがオレンジなのか• 「オレンジジュース」に由来 – 私は全くの下⼾（隔世遺伝） – 20数年前、会社の新⼈歓迎会で、後に直属の上司となる酒好きの某⽒（美⼈⼥性）の前で元気よくオレンジジュースを注⽂し、かつ「昭和40年代⽣まれ」であることを⾃慢したらしい（本⼈には⾃覚なし）• その某⽒（美⼈⼥性）が名付け親 – その⽅は当時の「業界の超有名⼈」 – UNIX MAGAZINEの⼈気連載に顛末を掲載 – 外部のさまざまな会議で私を「オレンジ」と紹介 ⇒ 内外に広く流通してしまった Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 5

本⽇の内容イマココ• 第⼀部: DNSをあえてdisってみる – DNSの⽋点や弱点を知る – ⽋点や弱点を知ることでより良く付き合う• 第⼆部: DNSトリビア（出張版） – twitterで不定期に配信 – DNSについて意外に知られていないこと – 知っていると得する（かも知れない?）こといわゆる「浸透問題」はこちらで取り上げます Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 6

本⽇の進め⽅• dnstudy #01と同じです（以下3⾏引⽤） – セミナーではなく勉強会です – 随時質問を受け付けます – 質問がある⽅は挙⼿をお願いします• ここでは個⼈の⽴場で話します – 本内容はすべて私の個⼈的⾒解であり、私の勤務先及び関係する団体などの公式⾒解ではありません• ということで、はじまりはじまり… Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 7

…の前に、念のために意識共有 ―今⽇のタイトル「disる」について―• リスペクト（敬意）の反対の意で、主にヒップホップ系のブラックミュージックアーティストやそのリスナー達の間で使われる⾔葉。⽇本語では、「ディスる」「ディスられる」という使い⽅をしている。 – http://ja.wikipedia.org/wiki/ディスリスペクト• 軽蔑し、攻撃すること。語源:disrespect（ディスリスペクト）＝軽蔑、無礼 – http://d.hatena.ne.jp/keyword/ディスる• 本来はdisではなくdissだという話もある – 参考1: http://en.wikipedia.org/wiki/Diss_track – 参考2: http://en.wiktionary.org/wiki/diss Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 8

構造上の宿命（1）• 上位の権威DNSサーバーほど負荷が集中する• 上位のDNSサービスが停⽌した場合、下位のすべてのゾーンが利⽤できなくなる – ルートサーバーやTLDのサーバーが落ちると⼤変• ルートサーバーのIPアドレスはおいそれとは変えられない – インターネット上のすべてのキャッシュDNSサーバーが持っている表（ヒント）に影響を及ぼす Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 10

「上位のサーバーほど負荷が集中」「上が落ちたら下は全部だめ」への対策• 複数の権威DNSサーバーを配置 – 負荷分散＆冗⻑化• IP Anycastの導⼊ – DNSプロトコル上の制限により、あるゾーンの権威 DNSサーバーとして設定できる最⼤数は13程度までとされている – それを超える数のサーバーを配置したい場合や、広域負荷分散を図りたい場合などに⽤いられる – 経路制御技術を活⽤ – ルートゾーンや⼤規模TLDなどで運⽤中 Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 12

でも…その分コストは上がる• 権威DNSサーバーを複数置いた場合、それらは全て同じ応答を返さなければならない – データの同期が必要 – 同期がうまくされないとトラブルの元になる – 意外に気づかないので注意が必要• IP Anycastの運⽤（特に広域）は⾊々と⼤変 – 管理対象の増加 – BGPのおもり・ヘルスチェック – 各所におけるピアリングやトランジットの調整 – 障害発⽣時のトラブルシューティングがやりづらい Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 13

「ルートサーバーのIPアドレスを変えることが⼤変」への対策• 根本的な対策はない ⇒「運⽤でカバー」 – できるだけ変わらないようにする • 専⽤のPIアドレスや専⽤のAS番号を割り当て – さまざまなチャンネルで告知する – 旧IPアドレスはしばらくの間再利⽤しない• 最近のIPアドレス変更例 – 2002年11⽉5⽇: J-root – 2004年1⽉29⽇: B-root – 2007年11⽉1⽇: L-root Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 14

「反復検索しなければいけない」への対策• 反復検索⽤サーバーの導⼊ – 反復検索をそのサーバーに依頼 – 各クライアントで反復検索をしなくてよくなる• キャッシュの導⼊ – 反復検索⽤サーバーに導⼊ – 各クライアントやアプリケーションでの導⼊も可能（ただし実装には注意が必要） – 検索結果の再利⽤により効率を向上 – 重い反復検索を毎回しなくてよくなる Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 15

でも…混乱する⼈多数• 反復検索⽤のサーバー（キャッシュDNSサーバー）も権威DNSサーバーと同様に「DNSサーバー」と呼ばれることとなった• 本来この2つは別の機能 – 委任ツリーをたどって名前解決するためのサーバー – 委任ツリーを構成するためのサーバー• この2つを混乱・混同する⼈が後を絶たない• キャッシュの導⼊に伴う新たな課題の発⽣ – 設定変更の反映に時間を要する – キャッシュの動作を考慮する必要がある – キャッシュポイズニングのリスクが⽣じる、など Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 16

「上位の権威DNSサーバーへの委任情報の登録が必要」への対策• DNSが⽣まれ持った、避けられない宿命• 下位ゾーンの委任情報を受け付け、⾃分の管理する権威DNSサーバーへの登録・公開を⾏う主体を、それぞれの階層ごとに導⼊する必要がある – DNSプロトコルの外で実装する必要がある• その役割を担当する組織を「レジストリ」と呼ぶ – つまり、レジストリが各階層ごとに必ず必要 Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 17

レジストリゆえの宿命• レジストリは1つのゾーンにつき1つのみ – レジストリ・レジストラモデルの導⼊ – レジストリ間における競争 – 新しいgTLDの導⼊（ICANN設⽴⽬的の⼀つ）• 特定のTLDへの負荷集中 – .com: 約9000万以上（世界全体の約4割弱） – .jp: 約125万• （以下、ここでは⾊々と⾃粛） – 懇親会ネタ? Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 18

今⽇取り上げる項⽬• 委任先（NS）を名前で指定している• データをプッシュするしくみがない• データを取り消すしくみがない• キャッシュの有効期限を絶対時刻で指定できない• ユーザーがキャッシュを制御するしくみがない• 主な通信プロトコルがUDPである• 「512の壁」が存在する• IDが16ビットしかない• 応答の正当性を検証するためのしくみがなかった Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 22

NSを名前で指定している• DNSでは委任先を名前（NS）で指定する – 例: example.jp. IN NS ns1.example.jp.• しかし、上記の場合この情報だけでは example.jpゾーン内の情報には絶対にアクセスできない• 「鶏卵問題」が発⽣する Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 23

鶏卵問題1. example.jpの権威DNSサーバーに到達するためには、ns1.example.jpのIPアドレスを知らなければならない2. ns1.example.jpのIPアドレスを知るには、example.jpの権威DNSサーバーに到達できなければならない3. 1.に戻る Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 24

解決:グルーレコードの導⼊• NSを応答する時、該当する名前に対する IPアドレスを「グルーレコード」として併せて応答する – 例: example.jp. IN NS ns1.example.jp. ns1.example.jp. IN A 192.0.2.1• グルー（glue: 糊）• これにより鶏卵問題を解決できる Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 25

グルーレコードの特性• NSで指定された名前が内部名(in- bailiwick name)である場合にのみ必要• 内部名とは? – そのゾーンの内側にある名前• example.jpのNSとして指定する場合… – ns1.example.jp 内部名 – ns2.example.jp 内部名 – ns1.sub.example.jp 内部名 – ns1.example.com 外部名 – ns1.example2.jp 外部名 Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 26

外部名の⽅がいい?• 外部名の場合、鶏卵問題がそもそも起こらないためグルーは不要 – 例: example.jp. IN NS ns1.example.com.• ドメイン名ごとにレジストリに登録が必要なもの（管理が必要なもの）が少なくて済む – 内部名の場合 • ネームサーバーホスト名とそのIPアドレス – 外部名の場合 • ネームサーバーホスト名のみ• じゃ、外部名のほうがいいのか? – そんなことはない！ Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 27

NSに外部名を指定するリスク• 「私は外部名で指定したゾーンを100%信⽤します」ということを意味している• もし、外部名で指定したゾーンを管理する権威 DNSサーバー（NSで指定したサーバーとは限らない）を乗っ取られた場合、NSで指定したサーバー⾃体が仮に無事であったとしても、⾃分のゾーンを乗っ取られるリスクが⽣じる• MXやCNAMEに外部名を指定するのも同様• なぜそうなるのか? – 続きを⾒ながら考えてみましょう Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 28

外部名の場合の名前解決⼿順• NSが外部名だった場合、現在取り掛かっている名前解決をいったん棚上げして、NSで指定されたホスト名のIPアドレスを解決する必要がある• そのホスト名のNSがまた外部名だった場合、名前解決を再び棚上げして、同様のことを繰り返す必要がある• 外部名の段数が多いと名前解決ができなくなる – 何段でできなくなるかは実装依存 – 3段を超えるとかなり危ない• NSの設定が互いに依存し合っている場合、名前解決ができなくなる（次ページ） Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 29

Sibling Glue• NSの設定内容が互いに依存し合っている – 例: example.jp. IN NS ns1.example.com. example.com. IN NS ns1.example.jp.• これは「sibling glue」と呼ばれ、 example.jpとexample.comの双⽅のゾーンとも名前解決ができなくなるので注意が必要• 3つ以上の依存関係もありうる Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 30

外部名のグルーはむしろ有害• そもそもns1.example.comのIPアドレスを、comゾーンを管理していないjpゾーンの権威DNSサーバーが教えていいのか? – そして、教えられた側は使ってよいのか?• 最近のキャッシュDNSサーバーの実装では、外部名のグルーが送られてきても無視する（捨てる） – 次ページ参照 Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 31

参考: かつて⾏われた外部名グルーによる攻撃• CERT Advisory CA-1997-22 BIND – http://www.cert.org/advisories/CA-1997-22.html• 外部名グルーを使って偽IPアドレスをキャッシュに送り込む – example.jp. IN NS www.example.com. www.example.com. IN A 192.0.2.1• 実際に www.internic.net が www.alternic.net に誘導され、⼤きな騒ぎになった• 脆弱性が存在した実装 – BIND4.9.6/8.1.1より前のバージョン – MS DNS (Windows 2000 Server) • デフォルト設定: レジストリで設定変更可能 Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 32

でも、考えてみたらグルーなんてそもそも必要なかったんじゃ?• そもそも「名前情報を委任する先を名前で指定する」という設計はセンスが悪いとしか⾔いようがない – 設計上の弱点 – 個⼈的には設計ミスに近いと思っている• 例えばこんな感じにすればよかったはず – example.jp. IN NSIP 192.0.2.1 – example.jp. IN NSIP6 2001:db8::1 Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 33

DNS最⼤のトラブル要因の⼀つはこうして作られた• Paul Mockapetrisさん（RFC 1034 / 1035の著者）が2002年に来⽇された際に直接聞きました• 回答の主旨: – 「当時はIPが出来たばかりで、将来IPの仕様が変わったり、IPではないプロトコルに対応する必要が⽣じる可能性があった。そのため、アドレスだけを変えられるようにサーバーは名前で指定し、対応するアドレスを糊付け（グルー）するというデザインを採⽤した。もちろん今ならそんな設計はしない」• 私「・・・。」 Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 34

DNSはオペレーションミスに冷たい• 間違ったデータを公開してしまった場合、データを修正してから古いデータが世界中のキャッシュから消えてなくなるまで「座して待つ」しかない• ひどい例:オペレーションミスにより、⼟曜⽇の午後11 時に「DNSキャッシュをフラッシュしてくださいー」という緊急アナウンスをしなければならなくなった – 2010年9⽉11⽇、 Nominet UK（.ukのレジストリ） • http://blog.nominet.org.uk/tech/wp- content/uploads/2010/09/dnssec-incident-report.pdf • “…we issued a technical announcement on Saturday evening at 11pm to alert resolver operators to ʻflushʼ their DNS caches.”（ただし、対象となったのはDNSSEC検証を有効にしていたキャッシュDNSサーバーのみであった） Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 36

データをプッシュするしくみがない• 権威DNSサーバー側からキャッシュDNSサーバーに対し、データを能動的に伝えるしくみが存在しない – 権威DNSサーバーは「来たら答える」のが基本• 昔はプライマリサーバー側からセカンダリサーバーに対し、データを能動的に伝えるしくみも存在しなかった – セカンダリサーバーが定期的にプライマリサーバーのSOA Serialをチェックし、増えていればゾーン転送をリクエスト – DNS NOTIFY（RFC 1996）で解決 Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 37

DNSはデータの更新に冷たい• 「このデータは更新されたから、キャッシュに残っていても新しいのに替えてね」と伝える機能がない• データの更新前にTTLを短くしておく必要あり – 緊急に更新したい場合には対応できない• 「じゃ、TTLを常に短くしておけばいいんじゃね?」 – 某CDNなど• しかし、常時TTLを短くするのはリスクを伴う – 参考:これでいいのかTTL ―短いDNS TTLのリスクを考える― • http://www.janog.gr.jp/meeting/janog19/files/DNS_Minda.pdf – DNSの系全体の負荷も増える • 権威DNSサーバー（⾃分の負荷） • キャッシュDNSサーバー（他⼈の負荷） Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 38

キャッシュの有効期限を絶対時刻で指定できない• DNSプロトコルではそもそも絶対時刻を使⽤していない – ただし、DNSSECを除く – DNSSECでは署名に有効期間（「期限」ではないことに注意）が存在する – SOAのシリアル番号は時刻ではない• TTLはキャッシュDNSサーバーがデータを受け取った時点からの減算タイマーとして機能 – データを受け取った時点からの相対時間 Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 39

DNSは切り替えがルーズ• データ公開時に「このキャッシュが有効なのは ○年○⽉○⽇○時○分○秒まで」という設定ができない• このため「○○○○に切り替わります」ではなく「○○○○までに徐々に切り替わります」というサービスしか提供できない• ただし、djbdns（tinydns）ではtimestamp指定という機能があり「その時刻が来たら設定を有効にする」「その時刻が来たら設定を無効にする」という設定をすることができる – 無効にする場合、tinydnsが返すTTLが指定した時刻に向け、1秒ずつ減っていく Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 40

ユーザーがキャッシュを制御するしくみがない• ユーザー（クライアント）がキャッシュDNS サーバーのキャッシュを外部から直接制御できるしくみが存在しない• もちろん、⾃分が管理しているキャッシュDNS サーバーのキャッシュを制御することは可能 – BIND 9ではrndc、Unboundではunbound-control コマンドによりキャッシュを制御できる• ユーザーが権威DNSサーバーのデータを外部から制御する（更新する）しくみは存在する – Dynamic Update（RFC 2136） Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 41

DNSはユーザーにも冷たい• 「元のデータがもう更新されているからすぐに読み直してちょ」という機能がない• もし、新規登録される前にその名前を引いてしまい、ネガティブキャッシュされてしまったら、それの期限切れまで「座して待つ」しかない• ⾃分が権限を持つゾーンぐらいはできてもいい?• しかし、実際にやろうとすると難しい – 認証をどうする? – DoS攻撃に使われないか? Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 42

主な通信プロトコルがUDPである• TCPと⽐較して発信元IPアドレスの詐称が容易である• これを悪⽤した攻撃が可能になる• UDPであるために攻撃しやすくなる例 – DNSの特性を悪⽤した攻撃 • DNS reflection（amplification）attack – DNSそのものへの攻撃 • キャッシュポイズニング Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 43

DNS reflection （amplification）attack 1. Botnetなどを利⽤し、攻撃⽤の巨⼤なデータをキャッシュDNSサーバーにキャッシュさせる 2. 各Botから攻撃対象のIPアドレスを詐称したDNS問い合わせを、キャッシュDNSサーバーに送信する 3. 問い合わせを受けたキャッシュDNSサーバーが、攻撃対象に対し巨⼤なDNS応答を返す DNSキャッシュサーバ DNSキャッシュサーバ TXT XXXXX・・・・・TXT XXXXX・・・・・ TXT XXXXX・・・・・：攻撃対象のコンピュータの TXT XXXXX・・・・・：：：・・・・・XXXXX ・・・・・XXXXX IPアドレスを騙って・・・・・XXXXX ・・・・・XXXXX 権威DNSサーバ TXT XXXXX・・・・・：一斉にDNS問い合わせを行う権威DNSサーバ TXT XXXXX・・・・・：・・・・・XXXXX ・・・・・XXXXX TXT XXXXX・・・・・攻撃用 TXT XXXXX・・・・・：指令：・・・・・XXXXX データが指令・・・・・XXXXX攻撃者 Botnet コピーされる攻撃者 Botnet TXT XXXXX・・・・・ TXT XXXXX・・・・・：：・・・・・XXXXX ・・・・・XXXXX 攻撃対象の攻撃対象の TXT XXXXX・・・・・ TXT XXXXX・・・・・コンピュータ：コンピュータ：・・・・・XXXXX ・・・・・XXXXX 図1 攻撃の準備図2 DNS Amp攻撃（図はhttp://jpinfo.jp/topics-column/003.pdf より引⽤） Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 44

キャッシュポイズニング• 古くて新しい攻撃⽅法• アドレスバーに表⽰されるURIが本物と同じになる example.jpのインターネットユーザーキャッシュDNSサーバー権威DNSサーバー（http://example.jp/へアクセス）１２５毒入れされた４３キャッシュサーバーによりフィッシングサイトへ誘導送信元のIPアドレスを詐称した正規のサイトフィッシングサイト偽の情報を送り付け、正しい応答の代わりに偽の情報がキャッシュされるように仕向けるログインID： taro ログインID： taro パスワード： ***** パスワード： ***** ３攻撃者インターネットユーザーは、フィッシングサイトに誘導されたことに気付かずにユーザーIDやパスワードを入力し、情報を盗まれてしまう（図はhttp://jpinfo.jp/topics-column/013.pdf より引⽤） Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 45

「512の壁」が存在する• 伝統的なDNSの仕様では通信プロトコルとして、 UDPを⽤いる場合のDNS応答のサイズを512オクテット（バイト）以下に制限• 伝統的なDNSの仕様では512オクテットを超える場合「TCP フォールバック」を使⽤ – まず最初にUDPを⽤い、応答の⼤きさが512オクテットを超え、応答の切り詰めが発⽣した場合にのみTCP を⽤いる• TCPフォールバックを使⽤することにより、 65,535オクテットまでのDNS応答を取り扱うことができる – あれ? 扱えるなら壁は存在しないんじゃ? Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 46

フォールバックはトラブルの素• フォールバックは遅い – 原則として⼀度UDPで試し、データの切り詰めを確認してからでないとTCPは使えない• データの切り詰めはDNS応答中の「TC ビット」により通知される – UDPによる最初の応答を受け取って中のフラグビットを確認するまで、データの切り詰めが起こったことを確認できない – つまり処理コストが⾼い Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 47

フォールバックはトラブルの素• 知識不⾜などにより、権威DNSサーバーの 53/tcpがファイアウォールなどでブロックされている場合がある – キャッシュDNSサーバーがTCP接続しようとして、処理が詰まってしまうことになる• EDNS0（RFC 2671）に対応することにより、 UDPのみで512オクテットを超える応答を取り扱える – 現在ではEDNS0を使うことが推奨されている – 問い合わせ側と応答側の双⽅における対応が必要 – EDNS0をうまく取り扱えないネットワーク製品が存在している Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 48

で、「512の壁」はそもそもどうしてできたのか• DNSは「1980年代のネットワーク品質」と「1980年代のコンピューターの性能」で使うことを前提に開発された• TCP/IP（IPv4）では⼀度に送信可能なデータの最⼤値として、少なくとも576オクテットを保証しなければならない、と定められていた – 実はこれは今でも有効 Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 49

「512の壁」はどうしてできたのか（続き）• そのため、1. IPヘッダ（20 オクテット）とUDP ヘッダ（８オクテット）を576から差し引いた値（548 オクテット)よりも⼩さく2. かつコンピューターにとって取り扱いが容易な2の乗数である… 「512オクテット」と定められた Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 50

ちなみに…• 1999年に標準化されたEDNS0では「ネットワークの信頼性やコンピューターの処理能⼒が⾶躍的に向上したので、通信プロトコルにUDP を⽤いていて、かつデータが分割・再構成されても⼤丈夫になった」ということが前提となっている• …と、RFC 2671にちゃんと書いてあります• こうして「ないはずの壁」だけが残ることに…• IPv6やDNSSECではEDNS0のサポートが必須とされている（RFC 3226） Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 51

IDが16ビットしかない• DNSでは、パケットを識別するためのID （問い合わせと応答には同じIDが割り当てられる）の⻑さが16ビットしかない – IDとして取りうる値は65536通りしかない• 現在のコンピューターやネットワークの能⼒からすると、ブルートフォースアタックに対する耐性が⼗分ではない• カミンスキー型攻撃⼿法が⼤きな脅威となり得た理由の⼀つ Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 52

キャッシュポイズニングが成⽴する確率⼤きいほど R W 確率が⼩さくなる PS  N  Port  IDR: 攻撃対象1台当たりに送るパケット量(pps)W: 攻撃可能な時間(問い合わせ⇒応答のRTT)N: 攻撃対象レコードを保持する権威DNSサーバの数Port: 問い合わせに使われるUDPポート番号の数ID: DNSのID (16bit = 65,536) （http://jpinfo.jp/topics-column/009.pdf より引⽤） Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 53

応答の正当性を検証するためのしくみがなかった• DNSには、応答の正当性（本当に正しいこと）を受信者が検証するためのしくみが準備されていなかった – 当時はそれでもよかった• そのため、受け取ったDNS応答の「送信元IPアドレス」「ポート番号」「クエリ名」「クエリ型」「ID」が適切なものであれば、正しいに違いないと判断して受け取ってしまう – 偽造されたものであると判断するための材料がない Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 55

後付けで追加されたDNSSEC• そのことが問題とされ、偽造されたものであると受信者が判断するための機能であるDNSSEC が開発された• 最初の論⽂執筆から.jpや.comにおける正式運⽤開始までに、20年以上の年⽉を要した – 詳細はこの資料を参照のこと • 桃栗三年柿⼋年、DNSSECは何年？ http://jprs.jp/tech/material/iw2009-lunch-L1-01.pdf• しかも、普及はまだ始まったばかり Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 56

数多くの機能拡張が⻑年に渡り逐次的に実施された• 基盤技術であるDNSはRFCの数が⾮常に多く、かつそれぞれのRFCにおいて部分的な機能拡張が数多くなされている• RFC 1034のUpdated by: 1101, 1183, 1348, 1876, 1982, 2065, 2181, 2308, 2535, 4033, 4034, 4035, 4343, 4592, 5936• RFC 1035のUpdated by: 1101, 1183, 1348, 1876, 1982, 1995, 1996, 2065, 2136, 2137, 2181, 2308, 2535, 2845, 3425, 3658, 4033, 4034, 4035, 4343, 5936, 5966• ./bind-9.8.1/doc/rfc には130本（！）もの RFCが⼊っている Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 60

数多くの機能拡張が⻑年に渡り逐次的に実施された• そのため、ある技術の全貌を知るためには数多くのRFCを参照し、その内容を理解する必要がある• この状況を解決するため、RFC 1034 / 1035をObsoleteにし、かつこれまでに実施された主な機能拡張を網羅した新たな RFCの発⾏がIETFにおいて計画されたが、現在まで実現に⾄っていない Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 61

実装依存な事項が多い• 細部の動作の具体的な仕様が定義されておらず、実装依存となっている事項がかなり多く存在している• 例を挙げると… – 複数あるNSのうちどれが選ばれるか – CNAMEの段数は何段まで許されるか – 既にキャッシュされている情報と同じ情報を改めて受け取った場合の取り扱い、など Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 62

数多く存在する「運⽤でカバー」• このような状況からDNSには「運⽤でカバー」している（する必要がある）事項が数多く存在している• DNS関連のBCP（Best Current Practice）の多さがそれを物語っている• 有名なBCP（他にもたくさんある） – クラスレスin-addr.arpaの委任（RFC 2317） – ルートサーバーの運⽤要件（RFC 2870） – DNSプロキシの実装ガイドライン（RFC 5625） Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 63

新しい技術を追加導⼊しにくい• 既に運⽤されている基盤技術に新しい技術を追加導⼊する場合、既存のものに影響を与えないように細⼼の注意を払う必要がある• 結果として新しい技術の追加導⼊に、多⼤な労⼒と時間を要することになる• DNS関連技術における例 – 国際化ドメイン名の導⼊ – ルートサーバーへのIPv6の導⼊ – DNSSECの導⼊ Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 64

フレッシュな技術者がなかなか⼊って来ない• このような状況からか、DNSを志すフレッシュな技術者がなかなか⼊って来ないという傾向がある• 「若者のインフラ離れ」 by @ibucho• IETFのDNS関連WGでがんばっている⾯々は、10年前と⼤きく変わっていない• “DNS is widely deployed, but its community is still small.” by Cricket Liu Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 65

最後に…• というわけで、DNSを⾊々とdisってみました• 今⽇取り上げたほとんどの項⽬には「現時点においてそうなっている理由」がちゃんとあります – それぞれについて勉強してみるとよいでしょう – 必要に応じて歴史的な経緯を勉強することも⼤切です• しかし、過去にばかりこだわってはいけません – 今後のよりよい未来を創るために役⽴ててほしいですそして、それでも私はDNSを愛しています Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 66

20111029 part1-dnsをあえてdisってみる-事後資料

by Yasuhiro Morishita on Oct 31, 2011

Accessibility

Categories

Upload Details

Usage Rights

2 Embeds 31

Statistics

20111029 part1-dnsをあえてdisってみる-事後資料 — Presentation Transcript

http://a0.twimg.com	27
http://paper.li	4