20111029 part1-dnsをあえてdisってみる-事後資料
- 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. Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 2
私は誰?
• 氏名: 森下 泰宏(もりした やすひろ)
– 1965年9月21日生まれ(46歳)男性
• 通称: オレンジさん
– 理由は少し後で説明します
– 呼ぶ時には苗字でも通称でも、お好きなほうでOKです
• twitter ID: @OrangeMorishita
• 現在の勤務先:
– 株式会社日本レジストリサービス(JPRS)
• 現在の肩書: 技術広報担当
- 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. Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 4
最近のお仕事
• いろいろ書く
– 書籍「実践DNS」(共著)
– JPRSトピックス&コラム
– JPRSメールマガジン「from JPRS」増刊号
• いろいろお知らせする
– 「重複をお許しください」
• いろいろ広報・宣伝する
– JPRS出展ブース(JANOG、Interopなど)
– Internet Weekランチセミナー
- 5. Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 5
なぜミドルネームがオレンジなのか
• 「オレンジジュース」に由来
– 私は全くの下⼾(隔世遺伝)
– 20数年前、会社の新人歓迎会で、後に直属の上司と
なる酒好きの某氏(美人⼥性)の前で元気よくオレ
ンジジュースを注文し、かつ「昭和40年代⽣まれ」
であることを自慢したらしい(本人には自覚なし)
• その某氏(美人⼥性)が名付け親
– その方は当時の「業界の超有名人」
– UNIX MAGAZINEの人気連載に顛末を掲載
– 外部のさまざまな会議で私を「オレンジ」と紹介
⇒ 内外に広く流通してしまった
- 6. Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 6
本日の内容
• 第一部: DNSをあえてdisってみる
– DNSの欠点や弱点を知る
– 欠点や弱点を知ることでより良く付き合う
• 第二部: DNSトリビア(出張版)
– twitterで不定期に配信
– DNSについて意外に知られていないこと
– 知っていると得する(かも知れない?)こと
いわゆる「浸透問題」はこちらで取り上げます
イマココ
- 7. Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 7
本日の進め方
• dnstudy #01と同じです(以下3⾏引⽤)
– セミナーではなく勉強会です
– 随時質問を受け付けます
– 質問がある方は挙手をお願いします
• ここでは個人の⽴場で話します
– 本内容はすべて私の個人的⾒解であり、私の勤務先
及び関係する団体などの公式⾒解ではありません
• ということで、はじまりはじまり…
- 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. Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 9
構造上の宿命ととられた対策
- 10. Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 10
構造上の宿命(1)
• 根元の権威DNSサーバーほど負荷が集中する
• 親のDNSサービスが停止した場合、その⼦孫の
すべてのゾーンが利⽤できなくなる
– ルートサーバーやTLDのサーバーが落ちると⼤変
• ルートサーバーのIPアドレスはおいそれとは変
えられない
– インターネット上のすべてのキャッシュDNSサー
バーが持っている表(ヒント)に影響を及ぼす
- 11. Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 11
構造上の宿命(2)
• 名前解決の際、各ゾーンの権威DNSサー
バーに対し反復検索をしなければならない
– 反復検索のコストは決して⼩さくない
– 時間もかかる
• 委任情報を、親ゾーンの権威DNSサー
バーにあらかじめ登録しておく必要がある
- 12. Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 12
「根元のサーバーほど負荷が集中」
「親が落ちたら⼦孫は全部だめ」への対策
• 複数の権威DNSサーバーを配置
– 負荷分散&冗⻑化
• IP Anycastの導入
– DNSプロトコル上の制限により、あるゾーンの権威
DNSサーバーとして設定できる最⼤数は13程度まで
とされている
– それを超える数のサーバーを配置したい場合や、広
域負荷分散を図りたい場合などに⽤いられる
– 経路制御技術を活⽤
– ルートゾーンや⼤規模TLDなどで運⽤中
- 13. Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 13
でも…その分コストは上がる
• 権威DNSサーバーを複数置いた場合、それらは
全て同じ応答を返さなければならない
– データの同期が必要
– 同期がうまくされないとトラブルの元になる
– 意外に気づかないので注意が必要
• IP Anycastの運⽤(特に広域)は色々と⼤変
– 管理対象の増加
– BGPのおもり・ヘルスチェック
– 各所におけるピアリングやトランジットの調整
– 障害発生時のトラブルシューティングがやりづらい
- 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. Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 15
「反復検索しなければいけない」
への対策
• 反復検索⽤サーバーの導入
– 反復検索をそのサーバーに依頼
– 各クライアントで反復検索をしなくてよくなる
• キャッシュの導入
– 反復検索⽤サーバーに導入
– 各クライアントやアプリケーションでの導入も
可能(ただし実装には注意が必要)
– 検索結果の再利⽤により効率を向上
– 重い反復検索を毎回しなくてよくなる
- 16. Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 16
でも…混乱する人多数
• 反復検索⽤のサーバー(キャッシュDNSサー
バー)も権威DNSサーバーと同様に「DNSサー
バー」と呼ばれることとなった
• 本来この2つは別の機能
– 委任ツリーをたどって名前解決するためのサーバー
– 委任ツリーを構成するためのサーバー
• この2つを混乱・混同する人が後を絶たない
• キャッシュの導入に伴う新たな課題の発生
– 設定変更の反映に時間を要する
– キャッシュの動作を考慮する必要がある
– キャッシュポイズニングのリスクが生じる、など
- 17. Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 17
「親の権威DNSサーバーへの
委任情報の登録が必要」への対策
• DNSが生まれ持った、避けられない宿命
• ⼦ゾーンの委任情報を受け付け、自分の管
理する権威DNSサーバーへの登録・公開を
⾏う主体を、それぞれの階層ごとに導入す
る必要がある
– DNSプロトコルの外で実装する必要がある
• その役割を担当する組織を「レジストリ」
と呼ぶ
– つまり、レジストリが各階層ごとに必ず必要
- 18. Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 18
レジストリゆえの宿命
• レジストリは1つのゾーンにつき1つのみ
– レジストリ・レジストラモデルの導入
– レジストリ間における競争
– 新しいgTLDの導入(ICANN設⽴目的の一つ)
• 特定のTLDへの負荷集中
– .com: 約9000万以上(世界全体の約4割弱)
– .jp: 約125万
• (以下、ここでは色々と自粛)
– 懇親会ネタ?
- 19. Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 19
過去のしがらみと
設計上の弱点
- 20. Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 20
過去のしがらみ
• 最初のDNSが誕生したのは1983年
– RFC 882/883
• 現在のDNSが誕生したのは1987年
– RFC 1034/1035
• 既に20年以上が経過
– さまざまな「過去のしがらみ」が存在する
- 21. Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 21
設計上の弱点
• 時代背景や設計当時の事情などから来る、
さまざまな設計上の弱点が存在する
• プロトコルの改良や機能拡張、運⽤上の
工夫などにより弱点のいくつかはかなり
の程度カバーされてきたが、本質的な弱
点が解消されているわけではない
- 22. Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 22
今日取り上げる項目
• 委任先(NS)を名前で指定している
• データをプッシュするしくみがない
• データを取り消すしくみがない
• キャッシュの有効期限を絶対時刻で指定できない
• ユーザーがキャッシュを制御するしくみがない
• 主な通信プロトコルがUDPである
• 「512の壁」が存在する
• IDが16ビットしかない
• 応答の正当性を検証するためのしくみがなかった
- 23. Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 23
NSを名前で指定している
• DNSでは委任先を名前(NS)で指定する
– 例: example.jp. IN NS ns1.example.jp.
• しかし、上記の場合この情報だけでは
example.jpゾーン内の情報には絶対にア
クセスできない
• 「鶏卵問題」が発生する
- 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. 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. 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. Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 27
外部名の方がいい?
• 外部名の場合、鶏卵問題がそもそも起こらない
⇒ グルーは存在しない
– 例: example.jp. IN NS ns1.example.com.
• ドメイン名ごとにレジストリに登録が必要なも
の(管理が必要なもの)が少なくて済む
– 内部名の場合
• ネームサーバーホスト名とそのIPアドレス
– 外部名の場合
• ネームサーバーホスト名のみ
• じゃ、外部名のほうがいいのか?
– そんなことはない!
- 28. Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 28
NSに外部名を指定するリスク
• 「私は外部名で指定したゾーンを100%信用し
ます」ということを意味している
• もし、外部名で指定したゾーンを管理する権威
DNSサーバー(NSで指定したサーバーとは限ら
ない)を乗っ取られた場合、NSで指定したサー
バー自体が仮に無事であったとしても、自分の
ゾーンを乗っ取られるリスクが生じる
• MXやCNAMEに外部名を指定するのも同様
• なぜそうなるのか?
– 続きを⾒ながら考えてみましょう
- 29. Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 29
外部名の場合の名前解決手順
• NSが外部名だった場合、現在取り掛かっている
名前解決をいったん棚上げして、NSで指定され
たホスト名のIPアドレスを解決する必要がある
• そのホスト名のNSがまた外部名だった場合、名
前解決を再び棚上げして、同様のことを繰り返
す必要がある
• 外部名の段数が多いと名前解決ができなくなる
– 何段でできなくなるかは実装依存
– 3段を超えるとかなり危ない
• NSの設定が互いに依存し合っている場合、名前
解決ができなくなる(次ページ)
- 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. Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 31
外部名の取り扱い
• そもそもns1.example.comのIPアドレス
を、comゾーンを管理していないjpゾー
ンの権威DNSサーバーが教えていいのか?
– そして、教えられた側は使ってよいのか?
• 最近のキャッシュDNSサーバーの実装で
は、委任情報として外部名が送られてき
ても無視する(捨てる)
– 次ページ参照
- 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. 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. Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 34
DNS最⼤のトラブル要因の一つは
こうして作られた
• Paul Mockapetrisさん(RFC 1034 / 1035の著
者)が2002年に来日された際に直接聞きました
• 回答の主旨:
– 「当時はIPが出来たばかりで、将来IPの仕様が変
わったり、IPではないプロトコルに対応する必要が
生じる可能性があった。そのため、アドレスだけを
変えられるようにサーバーは名前で指定し、対応す
るアドレスを糊付け(グルー)するというデザイン
を採⽤した。もちろん今ならそんな設計はしない」
• 私「・・・。」
- 35. Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 35
データを取り消すしくみがない
• 権威DNSサーバーでいったん公開した
データを取り消す(revokeする)ための
しくみが存在しない
• 間違った設定や不適切な設定をしてし
まった場合などに「い…今のはなし」と
いう設定(切り戻し)ができない
- 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. Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 37
データをプッシュするしくみがない
• 権威DNSサーバー側からキャッシュDNSサー
バーに対し、データを能動的に伝えるしくみが
存在しない
– 権威DNSサーバーは「来たら答える」のが基本
• 昔はプライマリサーバー側から各セカンダリ
サーバーに対し、データを能動的に伝えるしく
みも存在しなかった
– 各セカンダリサーバーが定期的にプライマリサー
バーのSOA Serialをチェックし、増えていればゾー
ン転送をリクエスト
– DNS NOTIFY(RFC 1996)で解決
- 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. Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 39
キャッシュの有効期限を
絶対時刻で指定できない
• DNSプロトコルではそもそも絶対時刻を
使⽤していない
– ただし、DNSSECを除く
– DNSSECでは署名に有効期間(「期限」では
ないことに注意)が存在する
– SOAのシリアル番号は時刻ではない
• TTLはキャッシュDNSサーバーがデータ
を受け取った時点からの減算タイマーと
して機能
– データを受け取った時点からの相対時間
- 40. Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 40
DNSは切り替えがルーズ
• データ公開時に「このキャッシュが有効なのは
○年○月○日○時○分○秒まで」という設定が
できない
• このため「○○○○に切り替わります」ではな
く「○○○○までに徐々に切り替わります」と
いうサービスしか提供できない
• ただし、djbdns(tinydns)ではtimestamp指
定という機能があり「その時刻が来たら設定を
有効にする」「その時刻が来たら設定を無効に
する」という設定をすることができる
– 無効にする場合、tinydnsが返すTTLが指定した時刻
に向け、1秒ずつ減っていく
- 41. Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 41
ユーザーがキャッシュを
制御するしくみがない
• ユーザー(クライアント)がキャッシュDNS
サーバーのキャッシュを外部から直接制御でき
るしくみが存在しない
• もちろん、自分が管理しているキャッシュDNS
サーバーのキャッシュを制御することは可能
– BIND 9ではrndc、Unboundではunbound-control
コマンドによりキャッシュを制御できる
• ユーザーが権威DNSサーバーのデータを外部か
ら制御する(更新する)しくみは存在する
– Dynamic Update(RFC 2136)
- 42. Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 42
DNSはユーザーにも冷たい
• 「元のデータがもう更新されているからすぐに
読み直してちょ」という機能がない
• もし、新規登録される前にその名前を引いてし
まい、ネガティブキャッシュされてしまったら、
それの期限切れまで「座して待つ」しかない
• 自分が権限を持つゾーンぐらいはできてもいい?
• しかし、実際にやろうとすると難しい
– 認証をどうする?
– DoS攻撃に使われないか?
- 43. Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 43
主な通信プロトコルがUDPである
• TCPと比較して発信元IPアドレスの詐称が
容易である
• これを悪⽤した攻撃が可能になる
• UDPであるために攻撃しやすくなる例
– DNSの特性を悪⽤した攻撃
• DNS reflection(amplification)attack
– DNSそのものへの攻撃
• キャッシュポイズニング
- 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. 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. 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. Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 47
フォールバックはトラブルの素
• フォールバックは遅い
– 原則として一度UDPで試し、データの切り詰
めを確認してからでないとTCPは使えない
• データの切り詰めはDNS応答中の「TC
ビット」により通知される
– UDPによる最初の応答を受け取って中のフラ
グビットを確認するまで、データの切り詰め
が起こったことを確認できない
– つまり処理コストが⾼い
- 48. Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 48
フォールバックはトラブルの素
• 知識不⾜などにより、権威DNSサーバーの
53/tcpがファイアウォールなどでブロックされ
ている場合がある
– キャッシュDNSサーバーがTCP接続しようとして、
処理が詰まってしまうことになる
• EDNS0(RFC 2671)に対応することにより、
UDPのみで512オクテットを超える応答を取り
扱える
– 現在ではEDNS0を使うことが推奨されている
– 問い合わせ側と応答側の双方における対応が必要
– EDNS0をうまく取り扱えないネットワーク製品が存
在している
- 49. Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 49
で、「512の壁」は
そもそもどうしてできたのか
• DNSは「1980年代のネットワーク品質」
と「1980年代のコンピューターの性能」
で使うことを前提に開発された
• TCP/IP(IPv4)では一度に送信可能な
データの最⼤値として、少なくとも576オ
クテットを保証しなければならない、と
定められていた
– 実はこれは今でも有効
- 50. Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 50
「512の壁」は
どうしてできたのか(続き)
• そのため、
1. IPヘッダ(20 オクテット)とUDP ヘッ
ダ(8オクテット)を576から差し引い
た値(548 オクテット)よりも⼩さく
2. かつコンピューターにとって取り扱いが
容易な2の乗数である…
「512オクテット」と定められた
- 51. Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 51
ちなみに…
• 1999年に標準化されたEDNS0では「ネット
ワークの信頼性やコンピューターの処理能⼒が
飛躍的に向上したので、通信プロトコルにUDP
を⽤いていて、かつデータが分割・再構成され
ても⼤丈夫になった」ということが前提となっ
ている
• …と、RFC 2671にちゃんと書いてあります
• こうして「ないはずの壁」だけが残ることに…
• IPv6やDNSSECではEDNS0のサポートが必須と
されている(RFC 3226)
- 52. Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 52
IDが16ビットしかない
• DNSでは、パケットを識別するためのID
(問い合わせと応答には同じIDが割り当
てられる)の⻑さが16ビットしかない
– IDとして取りうる値は65536通りしかない
• 現在のコンピューターやネットワークの
能⼒からすると、ブルートフォースア
タックに対する耐性が十分ではない
• カミンスキー型攻撃手法が大きな脅威と
なり得た理由の一つ
- 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. Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 54
せめて、32ビットに
しておいてほしかった…
(「実践DNS」118ページより引⽤)
- 55. Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 55
応答の正当性を検証するための
しくみがなかった
• DNSには、応答の正当性(本当に正しいこと)
を受信者が検証するためのしくみが準備されて
いなかった
– 当時はそれでもよかった
• そのため、受け取ったDNS応答の「送信元IPア
ドレス」「ポート番号」「クエリ名」「クエリ
型」「ID」が適切なものであれば、正しいに違
いないと判断して受け取ってしまう
– 偽造されたものであると判断するための材料がない
- 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. Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 57
で、「DNSSECをdisってみる」
• …については、また今度機会があれば、、、
• 期待していた人、ごめんなさい
• たぶんこれだけでおかわり3杯いけます(謎)
- 58. Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 58
基盤技術であるがゆえの
運⽤上の問題
- 59. Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 59
取り上げる項目
• 数多くの機能拡張が逐次的に実施された
• 実装依存な事項が多い
• 数多く存在する「運⽤でカバー」
• 新しい技術を追加導入しにくい
• フレッシュな技術者がなかなか入って来ない
- 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. Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 61
数多くの機能拡張が⻑年に渡り
逐次的に実施された
• そのため、ある技術の全貌を知るために
は数多くのRFCを参照し、その内容を理解
する必要がある
• この状況を解決するため、RFC 1034 /
1035をObsoleteにし、かつこれまでに実
施された主な機能拡張を網羅した新たな
RFCの発⾏がIETFにおいて計画されたが、
現在まで実現に至っていない
- 62. Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 62
実装依存な事項が多い
• 細部の動作の具体的な仕様が定義されて
おらず、実装依存となっている事項がか
なり多く存在している
• 例を挙げると…
– 複数あるNSのうちどれが選ばれるか
– CNAMEの段数は何段まで許されるか
– 既にキャッシュされている情報と同じ情報を
改めて受け取った場合の取り扱い、など
- 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. Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 64
新しい技術を追加導入しにくい
• 既に運⽤されている基盤技術に新しい技
術を追加導入する場合、既存のものに影
響を与えないように細心の注意を払う必
要がある
• 結果として新しい技術の追加導入に、多
⼤な労⼒と時間を要することになる
• DNS関連技術における例
– 国際化ドメイン名の導入
– ルートサーバーへのIPv6の導入
– DNSSECの導入
- 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. Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 66
最後に…
• というわけで、DNSを色々とdisってみました
• 今日取り上げたほとんどの項目には「現時点にお
いてそうなっている理由」がちゃんとあります
– それぞれについて勉強してみるとよいでしょう
– 必要に応じて歴史的な経緯を勉強することも⼤切です
• しかし、過去にばかりこだわってはいけません
– 今後のよりよい未来を創るために役⽴ててほしいです
そして、それでも私はDNSを愛しています
- 67. Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 67
ありがとうございました!
「DNSトリビア(出張版)」に
続きます