Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

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

9,227 views

Published on

Published in: Lifestyle

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

  1. 1. Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 1 DNSをあえてdisってみる DNS周辺技術勉強会 #dnstudy 02 2011年10月29日 森下 泰宏 2016年12月5日追記: この資料の記述には、既に古くなった箇所が存在するため注意が必要です。 また、2016年12月5日に最低限の修正をしています(資料中の⻘字部分)。 (修正内容:上位・下位を親・⼦(⼦孫)という記述に変更、スライド30の修正など)
  2. 2. Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 2 私は誰? • 氏名: 森下 泰宏(もりした やすひろ) – 1965年9月21日生まれ(46歳)男性 • 通称: オレンジさん – 理由は少し後で説明します – 呼ぶ時には苗字でも通称でも、お好きなほうでOKです • twitter ID: @OrangeMorishita • 現在の勤務先: – 株式会社日本レジストリサービス(JPRS) • 現在の肩書: 技術広報担当
  3. 3. Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 3 経歴、付き合いなど • ネットワークとの付き合い: 1986年から – 知人からもらった300ボーの音響カプラで人生変わり ました • UNIXとの付き合い: 1988年から – 「最新UNIX」という本で人生変わりました – 最初に触ったUNIX: 4.2BSD – 最初に管理したサーバー: VAX-11/750 • DNSとの付き合い: 1990年から – 最初に触ったBIND: 4.8.3 • より詳しい経歴: http://森下泰宏.jp
  4. 4. Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 4 最近のお仕事 • いろいろ書く – 書籍「実践DNS」(共著) – JPRSトピックス&コラム – JPRSメールマガジン「from JPRS」増刊号 • いろいろお知らせする – 「重複をお許しください」 • いろいろ広報・宣伝する – JPRS出展ブース(JANOG、Interopなど) – Internet Weekランチセミナー
  5. 5. Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 5 なぜミドルネームがオレンジなのか • 「オレンジジュース」に由来 – 私は全くの下⼾(隔世遺伝) – 20数年前、会社の新人歓迎会で、後に直属の上司と なる酒好きの某氏(美人⼥性)の前で元気よくオレ ンジジュースを注文し、かつ「昭和40年代⽣まれ」 であることを自慢したらしい(本人には自覚なし) • その某氏(美人⼥性)が名付け親 – その方は当時の「業界の超有名人」 – UNIX MAGAZINEの人気連載に顛末を掲載 – 外部のさまざまな会議で私を「オレンジ」と紹介 ⇒ 内外に広く流通してしまった
  6. 6. Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 6 本日の内容 • 第一部: DNSをあえてdisってみる – DNSの欠点や弱点を知る – 欠点や弱点を知ることでより良く付き合う • 第二部: DNSトリビア(出張版) – twitterで不定期に配信 – DNSについて意外に知られていないこと – 知っていると得する(かも知れない?)こと いわゆる「浸透問題」はこちらで取り上げます イマココ
  7. 7. Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 7 本日の進め方 • dnstudy #01と同じです(以下3⾏引⽤) – セミナーではなく勉強会です – 随時質問を受け付けます – 質問がある方は挙手をお願いします • ここでは個人の⽴場で話します – 本内容はすべて私の個人的⾒解であり、私の勤務先 及び関係する団体などの公式⾒解ではありません • ということで、はじまりはじまり…
  8. 8. Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 8 …の前に、念のために意識共有 ―今日のタイトル「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
  9. 9. Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 9 構造上の宿命ととられた対策
  10. 10. Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 10 構造上の宿命(1) • 根元の権威DNSサーバーほど負荷が集中する • 親のDNSサービスが停止した場合、その⼦孫の すべてのゾーンが利⽤できなくなる – ルートサーバーやTLDのサーバーが落ちると⼤変 • ルートサーバーのIPアドレスはおいそれとは変 えられない – インターネット上のすべてのキャッシュDNSサー バーが持っている表(ヒント)に影響を及ぼす
  11. 11. Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 11 構造上の宿命(2) • 名前解決の際、各ゾーンの権威DNSサー バーに対し反復検索をしなければならない – 反復検索のコストは決して⼩さくない – 時間もかかる • 委任情報を、親ゾーンの権威DNSサー バーにあらかじめ登録しておく必要がある
  12. 12. Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 12 「根元のサーバーほど負荷が集中」 「親が落ちたら⼦孫は全部だめ」への対策 • 複数の権威DNSサーバーを配置 – 負荷分散&冗⻑化 • IP Anycastの導入 – DNSプロトコル上の制限により、あるゾーンの権威 DNSサーバーとして設定できる最⼤数は13程度まで とされている – それを超える数のサーバーを配置したい場合や、広 域負荷分散を図りたい場合などに⽤いられる – 経路制御技術を活⽤ – ルートゾーンや⼤規模TLDなどで運⽤中
  13. 13. Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 13 でも…その分コストは上がる • 権威DNSサーバーを複数置いた場合、それらは 全て同じ応答を返さなければならない – データの同期が必要 – 同期がうまくされないとトラブルの元になる – 意外に気づかないので注意が必要 • IP Anycastの運⽤(特に広域)は色々と⼤変 – 管理対象の増加 – BGPのおもり・ヘルスチェック – 各所におけるピアリングやトランジットの調整 – 障害発生時のトラブルシューティングがやりづらい
  14. 14. Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 14 「ルートサーバーのIPアドレスを 変えることが⼤変」への対策 • 根本的な対策はない ⇒「運⽤でカバー」 – できるだけ変わらないようにする • 専⽤のPIアドレスや専⽤のAS番号を割り当て – さまざまなチャンネルで告知する – 旧IPアドレスはしばらくの間再利⽤しない • 最近のIPアドレス変更例 – 2002年11月5日: J-root – 2004年1月29日: B-root – 2007年11月1日: L-root
  15. 15. Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 15 「反復検索しなければいけない」 への対策 • 反復検索⽤サーバーの導入 – 反復検索をそのサーバーに依頼 – 各クライアントで反復検索をしなくてよくなる • キャッシュの導入 – 反復検索⽤サーバーに導入 – 各クライアントやアプリケーションでの導入も 可能(ただし実装には注意が必要) – 検索結果の再利⽤により効率を向上 – 重い反復検索を毎回しなくてよくなる
  16. 16. Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 16 でも…混乱する人多数 • 反復検索⽤のサーバー(キャッシュDNSサー バー)も権威DNSサーバーと同様に「DNSサー バー」と呼ばれることとなった • 本来この2つは別の機能 – 委任ツリーをたどって名前解決するためのサーバー – 委任ツリーを構成するためのサーバー • この2つを混乱・混同する人が後を絶たない • キャッシュの導入に伴う新たな課題の発生 – 設定変更の反映に時間を要する – キャッシュの動作を考慮する必要がある – キャッシュポイズニングのリスクが生じる、など
  17. 17. Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 17 「親の権威DNSサーバーへの 委任情報の登録が必要」への対策 • DNSが生まれ持った、避けられない宿命 • ⼦ゾーンの委任情報を受け付け、自分の管 理する権威DNSサーバーへの登録・公開を ⾏う主体を、それぞれの階層ごとに導入す る必要がある – DNSプロトコルの外で実装する必要がある • その役割を担当する組織を「レジストリ」 と呼ぶ – つまり、レジストリが各階層ごとに必ず必要
  18. 18. Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 18 レジストリゆえの宿命 • レジストリは1つのゾーンにつき1つのみ – レジストリ・レジストラモデルの導入 – レジストリ間における競争 – 新しいgTLDの導入(ICANN設⽴目的の一つ) • 特定のTLDへの負荷集中 – .com: 約9000万以上(世界全体の約4割弱) – .jp: 約125万 • (以下、ここでは色々と自粛) – 懇親会ネタ?
  19. 19. Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 19 過去のしがらみと 設計上の弱点
  20. 20. Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 20 過去のしがらみ • 最初のDNSが誕生したのは1983年 – RFC 882/883 • 現在のDNSが誕生したのは1987年 – RFC 1034/1035 • 既に20年以上が経過 – さまざまな「過去のしがらみ」が存在する
  21. 21. Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 21 設計上の弱点 • 時代背景や設計当時の事情などから来る、 さまざまな設計上の弱点が存在する • プロトコルの改良や機能拡張、運⽤上の 工夫などにより弱点のいくつかはかなり の程度カバーされてきたが、本質的な弱 点が解消されているわけではない
  22. 22. Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 22 今日取り上げる項目 • 委任先(NS)を名前で指定している • データをプッシュするしくみがない • データを取り消すしくみがない • キャッシュの有効期限を絶対時刻で指定できない • ユーザーがキャッシュを制御するしくみがない • 主な通信プロトコルがUDPである • 「512の壁」が存在する • IDが16ビットしかない • 応答の正当性を検証するためのしくみがなかった
  23. 23. Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 23 NSを名前で指定している • DNSでは委任先を名前(NS)で指定する – 例: example.jp. IN NS ns1.example.jp. • しかし、上記の場合この情報だけでは example.jpゾーン内の情報には絶対にア クセスできない • 「鶏卵問題」が発生する
  24. 24. Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 24 鶏卵問題 1. example.jpの権威DNSサーバーに到達 するためには、ns1.example.jpのIPア ドレスを知らなければならない 2. ns1.example.jpのIPアドレスを知るに は、example.jpの権威DNSサーバーに 到達できなければならない 3. 1.に戻る
  25. 25. Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 25 解決:グルーレコードの導入 • NSを応答する時、該当する名前に対する IPアドレスを「グルーレコード」として 併せて応答する – 例: example.jp. IN NS ns1.example.jp. ns1.example.jp. IN A 192.0.2.1 • グルー(glue: 糊) • これにより鶏卵問題を解決できる
  26. 26. Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 26 グルーレコードの特性 • NSで指定された名前が内部名(in- bailiwick name)である場合にのみ必要 • 内部名とは? – そのゾーンの内側にある名前 • example.jpのNSとして指定する場合… – ns1.example.jp – ns2.example.jp – ns1.sub.example.jp – ns1.example.com – ns1.example2.jp 内部名 内部名 内部名 外部名 外部名
  27. 27. Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 27 外部名の方がいい? • 外部名の場合、鶏卵問題がそもそも起こらない ⇒ グルーは存在しない – 例: example.jp. IN NS ns1.example.com. • ドメイン名ごとにレジストリに登録が必要なも の(管理が必要なもの)が少なくて済む – 内部名の場合 • ネームサーバーホスト名とそのIPアドレス – 外部名の場合 • ネームサーバーホスト名のみ • じゃ、外部名のほうがいいのか? – そんなことはない!
  28. 28. Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 28 NSに外部名を指定するリスク • 「私は外部名で指定したゾーンを100%信用し ます」ということを意味している • もし、外部名で指定したゾーンを管理する権威 DNSサーバー(NSで指定したサーバーとは限ら ない)を乗っ取られた場合、NSで指定したサー バー自体が仮に無事であったとしても、自分の ゾーンを乗っ取られるリスクが生じる • MXやCNAMEに外部名を指定するのも同様 • なぜそうなるのか? – 続きを⾒ながら考えてみましょう
  29. 29. Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 29 外部名の場合の名前解決手順 • NSが外部名だった場合、現在取り掛かっている 名前解決をいったん棚上げして、NSで指定され たホスト名のIPアドレスを解決する必要がある • そのホスト名のNSがまた外部名だった場合、名 前解決を再び棚上げして、同様のことを繰り返 す必要がある • 外部名の段数が多いと名前解決ができなくなる – 何段でできなくなるかは実装依存 – 3段を超えるとかなり危ない • NSの設定が互いに依存し合っている場合、名前 解決ができなくなる(次ページ)
  30. 30. Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 30 NS設定内容の相互依存 • NSの設定内容が互いに依存し合っている – 例: example.jp. IN NS ns1.example.com. example.com. IN NS ns1.example.jp. • このような設定をした場合、example.jp とexample.comの双方のゾーンとも名前 解決ができなくなる危険性があるため注 意が必要 • 3つ以上の相互依存関係もありうる
  31. 31. Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 31 外部名の取り扱い • そもそもns1.example.comのIPアドレス を、comゾーンを管理していないjpゾー ンの権威DNSサーバーが教えていいのか? – そして、教えられた側は使ってよいのか? • 最近のキャッシュDNSサーバーの実装で は、委任情報として外部名が送られてき ても無視する(捨てる) – 次ページ参照
  32. 32. Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 32 参考: かつて⾏われた 外部名による攻撃 • 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 に誘導され、⼤きな騒ぎになった • 脆弱性が存在した実装 – BIND 4.9.6/8.1.1より前のバージョン – MS DNS (Windows 2000 Serverに付属) • デフォルト設定: レジストリにより設定変更可能
  33. 33. Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 33 でも、考えてみたらグルーなんて そもそも必要なかったんじゃ? • そもそも「名前情報を委任する先を名前 で指定する」という設計はセンスが悪い としか⾔いようがない – 設計上の弱点 – 個人的には設計ミスに近いと思っている • 例えばこんな感じにすればよかったはず – example.jp. IN NSIP 192.0.2.1 – example.jp. IN NSIP6 2001:db8::1
  34. 34. Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 34 DNS最⼤のトラブル要因の一つは こうして作られた • Paul Mockapetrisさん(RFC 1034 / 1035の著 者)が2002年に来日された際に直接聞きました • 回答の主旨: – 「当時はIPが出来たばかりで、将来IPの仕様が変 わったり、IPではないプロトコルに対応する必要が 生じる可能性があった。そのため、アドレスだけを 変えられるようにサーバーは名前で指定し、対応す るアドレスを糊付け(グルー)するというデザイン を採⽤した。もちろん今ならそんな設計はしない」 • 私「・・・。」
  35. 35. Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 35 データを取り消すしくみがない • 権威DNSサーバーでいったん公開した データを取り消す(revokeする)ための しくみが存在しない • 間違った設定や不適切な設定をしてし まった場合などに「い…今のはなし」と いう設定(切り戻し)ができない
  36. 36. Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 36 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サーバーのみであった)
  37. 37. Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 37 データをプッシュするしくみがない • 権威DNSサーバー側からキャッシュDNSサー バーに対し、データを能動的に伝えるしくみが 存在しない – 権威DNSサーバーは「来たら答える」のが基本 • 昔はプライマリサーバー側から各セカンダリ サーバーに対し、データを能動的に伝えるしく みも存在しなかった – 各セカンダリサーバーが定期的にプライマリサー バーのSOA Serialをチェックし、増えていればゾー ン転送をリクエスト – DNS NOTIFY(RFC 1996)で解決
  38. 38. Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 38 DNSはデータの更新に冷たい • 「このデータは更新されたから、キャッシュに残ってい ても新しいのに替えてね」と伝える機能がない • データの更新前にTTLを短くしておく必要あり – 緊急に更新したい場合には対応できない • 「じゃ、TTLを常に短くしておけばいいんじゃね?」 – 某CDNなど • しかし、常にTTLを短くすることはリスクを伴う – 参考:これでいいのかTTL ―短いDNS TTLのリスクを考える― • http://www.janog.gr.jp/meeting/janog19/files/DNS_Minda.pdf – DNSの系全体の負荷も増える • 権威DNSサーバー(自分の負荷) • キャッシュDNSサーバー(他人の負荷)
  39. 39. Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 39 キャッシュの有効期限を 絶対時刻で指定できない • DNSプロトコルではそもそも絶対時刻を 使⽤していない – ただし、DNSSECを除く – DNSSECでは署名に有効期間(「期限」では ないことに注意)が存在する – SOAのシリアル番号は時刻ではない • TTLはキャッシュDNSサーバーがデータ を受け取った時点からの減算タイマーと して機能 – データを受け取った時点からの相対時間
  40. 40. Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 40 DNSは切り替えがルーズ • データ公開時に「このキャッシュが有効なのは ○年○月○日○時○分○秒まで」という設定が できない • このため「○○○○に切り替わります」ではな く「○○○○までに徐々に切り替わります」と いうサービスしか提供できない • ただし、djbdns(tinydns)ではtimestamp指 定という機能があり「その時刻が来たら設定を 有効にする」「その時刻が来たら設定を無効に する」という設定をすることができる – 無効にする場合、tinydnsが返すTTLが指定した時刻 に向け、1秒ずつ減っていく
  41. 41. Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 41 ユーザーがキャッシュを 制御するしくみがない • ユーザー(クライアント)がキャッシュDNS サーバーのキャッシュを外部から直接制御でき るしくみが存在しない • もちろん、自分が管理しているキャッシュDNS サーバーのキャッシュを制御することは可能 – BIND 9ではrndc、Unboundではunbound-control コマンドによりキャッシュを制御できる • ユーザーが権威DNSサーバーのデータを外部か ら制御する(更新する)しくみは存在する – Dynamic Update(RFC 2136)
  42. 42. Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 42 DNSはユーザーにも冷たい • 「元のデータがもう更新されているからすぐに 読み直してちょ」という機能がない • もし、新規登録される前にその名前を引いてし まい、ネガティブキャッシュされてしまったら、 それの期限切れまで「座して待つ」しかない • 自分が権限を持つゾーンぐらいはできてもいい? • しかし、実際にやろうとすると難しい – 認証をどうする? – DoS攻撃に使われないか?
  43. 43. Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 43 主な通信プロトコルがUDPである • TCPと比較して発信元IPアドレスの詐称が 容易である • これを悪⽤した攻撃が可能になる • UDPであるために攻撃しやすくなる例 – DNSの特性を悪⽤した攻撃 • DNS reflection(amplification)attack – DNSそのものへの攻撃 • キャッシュポイズニング
  44. 44. Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 44 DNS reflection (amplification)attack TXT XXXXX・・・・・ : ・・・・・XXXXX 攻撃対象の コンピュータ 攻撃対象の コンピュータ BotnetBotnet攻撃者攻撃者 TXT XXXXX・・・・・ : ・・・・・XXXXX TXT XXXXX・・・・・ : ・・・・・XXXXX TXT XXXXX・・・・・ : ・・・・・XXXXX TXT XXXXX・・・・・ : ・・・・・XXXXX TXT XXXXX・・・・・ : ・・・・・XXXXX 攻撃用 データが コピーされる TXT XXXXX・・・・・ : ・・・・・XXXXX TXT XXXXX・・・・・ : ・・・・・XXXXX TXT XXXXX・・・・・ : ・・・・・XXXXX TXT XXXXX・・・・・ : ・・・・・XXXXX TXT XXXXX・・・・・ : ・・・・・XXXXX TXT XXXXX・・・・・ : ・・・・・XXXXX TXT XXXXX・・・・・ : ・・・・・XXXXX TXT XXXXX・・・・・ : ・・・・・XXXXX TXT XXXXX・・・・・ : ・・・・・XXXXX TXT XXXXX・・・・・ : ・・・・・XXXXX 攻撃用 データが コピーされる 権威DNSサーバ権威DNSサーバ DNSキャッシュサーバ 指令 図1 攻撃の準備 TXT XXXXX・・・・・ : ・・・・・XXXXX TXT XXXXX・・・・・ : ・・・・・XXXXX TXT XXXXX・・・・・ : ・・・・・XXXXX TXT XXXXX・・・・・ : ・・・・・XXXXX TXT XXXXX・・・・・ : ・・・・・XXXXX DNSキャッシュサーバ TXT XXXXX・・・・・ : ・・・・・XXXXX Botnet攻撃者 権威DNSサーバ 攻撃対象のコンピュータの IPアドレスを騙って 一斉にDNS問い合わせを行う 攻撃対象の コンピュータ 図2 DNS Amp攻撃 指令 TXT XXXXX・・・・・ : ・・・・・XXXXX TXT XXXXX・・・・・ : ・・・・・XXXXX TXT XXXXX・・・・・ : ・・・・・XXXXX TXT XXXXX・・・・・ : ・・・・・XXXXX TXT XXXXX・・・・・ : ・・・・・XXXXX TXT XXXXX・・・・・ : ・・・・・XXXXX TXT XXXXX・・・・・ : ・・・・・XXXXX TXT XXXXX・・・・・ : ・・・・・XXXXX TXT XXXXX・・・・・ : ・・・・・XXXXX TXT XXXXX・・・・・ : ・・・・・XXXXX TXT XXXXX・・・・・ : ・・・・・XXXXX TXT XXXXX・・・・・ : ・・・・・XXXXX TXT XXXXX・・・・・ : ・・・・・XXXXX TXT XXXXX・・・・・ : ・・・・・XXXXX TXT XXXXX・・・・・ : ・・・・・XXXXX DNSキャッシュサーバ TXT XXXXX・・・・・ : ・・・・・XXXXX Botnet攻撃者 権威DNSサーバ 攻撃対象のコンピュータの IPアドレスを騙って 一斉にDNS問い合わせを行う 攻撃対象の コンピュータ 図2 DNS Amp攻撃 指令 TXT XXXXX・・・・・ : ・・・・・XXXXX BotnetBotnet攻撃者攻撃者 権威DNSサーバ権威DNSサーバ 攻撃対象のコンピュータの IPアドレスを騙って 一斉にDNS問い合わせを行う 攻撃対象の コンピュータ 図2 DNS Amp攻撃 指令 1. Botnetなどを利⽤し、攻撃⽤の巨⼤なデータをキャッ シュDNSサーバーにキャッシュさせる 2. 各Botから攻撃対象のIPアドレスを詐称したDNS問い合 わせを、キャッシュDNSサーバーに送信する 3. 問い合わせを受けたキャッシュDNSサーバーが、攻撃 対象に対し巨⼤なDNS応答を返す (図はhttp://jpinfo.jp/topics-column/003.pdf より引⽤)
  45. 45. Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 45 キャッシュポイズニング (図はhttp://jpinfo.jp/topics-column/013.pdf より引⽤) taro ***** ログインID: パスワード: taro ***** ログインID: パスワード: 正規のサイト キャッシュDNSサーバーインターネットユーザー taro ***** ログインID: パスワード: taro ***** ログインID: パスワード: フィッシングサイト 1 45 (http://example.jp/へアクセス) 毒入れされた キャッシュサーバーにより フィッシングサイトへ誘導 インターネットユーザーは、 フィッシングサイトに誘導されたことに気付かずに ユーザーIDやパスワードを入力し、情報を盗まれてしまう 攻撃者 2 3 3 送信元のIPアドレスを詐称した 偽の情報を送り付け、正しい応答の代わりに 偽の情報がキャッシュされるように仕向ける example.jpの 権威DNSサーバー • 古くて新しい攻撃方法 • アドレスバーに表示されるURIが本物と同じになる
  46. 46. Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 46 「512の壁」が存在する • 伝統的なDNSの仕様では通信プロトコルとして、 UDPを⽤いる場合のDNS応答のサイズを512オ クテット(バイト)以下に制限 • 伝統的なDNSの仕様では512オクテットを超え る場合「TCP フォールバック」を使⽤ – まず最初にUDPを⽤い、応答の⼤きさが512オクテッ トを超え、応答の切り詰めが発生した場合にのみTCP を⽤いる • TCPフォールバックを使⽤することにより、 65,535オクテットまでのDNS応答を取り扱うこ とができる – あれ? 扱えるなら壁は存在しないんじゃ?
  47. 47. Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 47 フォールバックはトラブルの素 • フォールバックは遅い – 原則として一度UDPで試し、データの切り詰 めを確認してからでないとTCPは使えない • データの切り詰めはDNS応答中の「TC ビット」により通知される – UDPによる最初の応答を受け取って中のフラ グビットを確認するまで、データの切り詰め が起こったことを確認できない – つまり処理コストが⾼い
  48. 48. Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 48 フォールバックはトラブルの素 • 知識不⾜などにより、権威DNSサーバーの 53/tcpがファイアウォールなどでブロックされ ている場合がある – キャッシュDNSサーバーがTCP接続しようとして、 処理が詰まってしまうことになる • EDNS0(RFC 2671)に対応することにより、 UDPのみで512オクテットを超える応答を取り 扱える – 現在ではEDNS0を使うことが推奨されている – 問い合わせ側と応答側の双方における対応が必要 – EDNS0をうまく取り扱えないネットワーク製品が存 在している
  49. 49. Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 49 で、「512の壁」は そもそもどうしてできたのか • DNSは「1980年代のネットワーク品質」 と「1980年代のコンピューターの性能」 で使うことを前提に開発された • TCP/IP(IPv4)では一度に送信可能な データの最⼤値として、少なくとも576オ クテットを保証しなければならない、と 定められていた – 実はこれは今でも有効
  50. 50. Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 50 「512の壁」は どうしてできたのか(続き) • そのため、 1. IPヘッダ(20 オクテット)とUDP ヘッ ダ(8オクテット)を576から差し引い た値(548 オクテット)よりも⼩さく 2. かつコンピューターにとって取り扱いが 容易な2の乗数である… 「512オクテット」と定められた
  51. 51. Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 51 ちなみに… • 1999年に標準化されたEDNS0では「ネット ワークの信頼性やコンピューターの処理能⼒が 飛躍的に向上したので、通信プロトコルにUDP を⽤いていて、かつデータが分割・再構成され ても⼤丈夫になった」ということが前提となっ ている • …と、RFC 2671にちゃんと書いてあります • こうして「ないはずの壁」だけが残ることに… • IPv6やDNSSECではEDNS0のサポートが必須と されている(RFC 3226)
  52. 52. Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 52 IDが16ビットしかない • DNSでは、パケットを識別するためのID (問い合わせと応答には同じIDが割り当 てられる)の⻑さが16ビットしかない – IDとして取りうる値は65536通りしかない • 現在のコンピューターやネットワークの 能⼒からすると、ブルートフォースア タックに対する耐性が十分ではない • カミンスキー型攻撃手法が大きな脅威と なり得た理由の一つ
  53. 53. Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 53 キャッシュポイズニングが 成⽴する確率 IDPortN WR PS ×× × = R: 攻撃対象1台当たりに送るパケット量(pps) W: 攻撃可能な時間(問い合わせ⇒応答のRTT) N: 攻撃対象レコードを保持する権威DNSサーバの数 Port: 問い合わせに使われるUDPポート番号の数 ID: DNSのID (16bit = 65,536) (http://jpinfo.jp/topics-column/009.pdf より引⽤) ⼤きいほど 確率が⼩さくなる
  54. 54. Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 54 せめて、32ビットに しておいてほしかった… (「実践DNS」118ページより引⽤)
  55. 55. Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 55 応答の正当性を検証するための しくみがなかった • DNSには、応答の正当性(本当に正しいこと) を受信者が検証するためのしくみが準備されて いなかった – 当時はそれでもよかった • そのため、受け取ったDNS応答の「送信元IPア ドレス」「ポート番号」「クエリ名」「クエリ 型」「ID」が適切なものであれば、正しいに違 いないと判断して受け取ってしまう – 偽造されたものであると判断するための材料がない
  56. 56. Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 56 後付けで追加されたDNSSEC • そのことが問題とされ、偽造されたものである と受信者が判断するための機能であるDNSSEC が開発された • 最初の論文執筆から.jpや.comにおける正式運 ⽤開始までに、20年以上の年⽉を要した – 詳細はこの資料を参照のこと • 桃栗三年柿⼋年、DNSSECは何年? http://jprs.jp/tech/material/iw2009-lunch-L1-01.pdf • しかも、普及はまだ始まったばかり
  57. 57. Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 57 で、「DNSSECをdisってみる」 • …については、また今度機会があれば、、、 • 期待していた人、ごめんなさい • たぶんこれだけでおかわり3杯いけます(謎)
  58. 58. Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 58 基盤技術であるがゆえの 運⽤上の問題
  59. 59. Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 59 取り上げる項目 • 数多くの機能拡張が逐次的に実施された • 実装依存な事項が多い • 数多く存在する「運⽤でカバー」 • 新しい技術を追加導入しにくい • フレッシュな技術者がなかなか入って来ない
  60. 60. Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 60 数多くの機能拡張が⻑年に渡り 逐次的に実施された • 基盤技術である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が入っている
  61. 61. Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 61 数多くの機能拡張が⻑年に渡り 逐次的に実施された • そのため、ある技術の全貌を知るために は数多くのRFCを参照し、その内容を理解 する必要がある • この状況を解決するため、RFC 1034 / 1035をObsoleteにし、かつこれまでに実 施された主な機能拡張を網羅した新たな RFCの発⾏がIETFにおいて計画されたが、 現在まで実現に至っていない
  62. 62. Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 62 実装依存な事項が多い • 細部の動作の具体的な仕様が定義されて おらず、実装依存となっている事項がか なり多く存在している • 例を挙げると… – 複数あるNSのうちどれが選ばれるか – CNAMEの段数は何段まで許されるか – 既にキャッシュされている情報と同じ情報を 改めて受け取った場合の取り扱い、など
  63. 63. Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 63 数多く存在する「運⽤でカバー」 • このような状況からDNSには「運⽤でカ バー」している(する必要がある)事項が数 多く存在している • DNS関連のBCP(Best Current Practice) の多さがそれを物語っている • 有名なBCP(他にもたくさんある) – クラスレスin-addr.arpaの委任(RFC 2317) – ルートサーバーの運⽤要件(RFC 2870) – DNSプロキシの実装ガイドライン(RFC 5625)
  64. 64. Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 64 新しい技術を追加導入しにくい • 既に運⽤されている基盤技術に新しい技 術を追加導入する場合、既存のものに影 響を与えないように細心の注意を払う必 要がある • 結果として新しい技術の追加導入に、多 ⼤な労⼒と時間を要することになる • DNS関連技術における例 – 国際化ドメイン名の導入 – ルートサーバーへのIPv6の導入 – DNSSECの導入
  65. 65. Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 65 フレッシュな技術者が なかなか入って来ない • このような状況からか、DNSを志すフレッ シュな技術者がなかなか入って来ないとい う傾向がある • 「若者のインフラ離れ」 by @ibucho • IETFのDNS関連WGでがんばっている面々 は、10年前と⼤きく変わっていない • “DNS is widely deployed, but its community is still small.” by Cricket Liu
  66. 66. Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 66 最後に… • というわけで、DNSを色々とdisってみました • 今日取り上げたほとんどの項目には「現時点にお いてそうなっている理由」がちゃんとあります – それぞれについて勉強してみるとよいでしょう – 必要に応じて歴史的な経緯を勉強することも⼤切です • しかし、過去にばかりこだわってはいけません – 今後のよりよい未来を創るために役⽴ててほしいです そして、それでも私はDNSを愛しています
  67. 67. Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 67 ありがとうございました! 「DNSトリビア(出張版)」に 続きます

×