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.
Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 1
DNSをあえてdisってみる
DNS周辺技術勉強会 #dnstudy 02
2011年10月29日
森下 泰宏...
Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 2
私は誰?
• 氏名: 森下 泰宏(もりした やすひろ)
– 1965年9月21日生まれ(46歳)男性
• 通称...
Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 3
経歴、付き合いなど
• ネットワークとの付き合い: 1986年から
– 知人からもらった300ボーの音響カプラ...
Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 4
最近のお仕事
• いろいろ書く
– 書籍「実践DNS」(共著)
– JPRSトピックス&コラム
– JPRSメ...
Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 5
なぜミドルネームがオレンジなのか
• 「オレンジジュース」に由来
– 私は全くの下⼾(隔世遺伝)
– 20数年...
Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 6
本日の内容
• 第一部: DNSをあえてdisってみる
– DNSの欠点や弱点を知る
– 欠点や弱点を知ること...
Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 7
本日の進め方
• dnstudy #01と同じです(以下3⾏引⽤)
– セミナーではなく勉強会です
– 随時質...
Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 8
…の前に、念のために意識共有
―今日のタイトル「disる」について―
• リスペクト(敬意)の反対の意で、主に...
Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 9
構造上の宿命ととられた対策
Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 10
構造上の宿命(1)
• 根元の権威DNSサーバーほど負荷が集中する
• 親のDNSサービスが停止した場合、そ...
Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 11
構造上の宿命(2)
• 名前解決の際、各ゾーンの権威DNSサー
バーに対し反復検索をしなければならない
– ...
Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 12
「根元のサーバーほど負荷が集中」
「親が落ちたら⼦孫は全部だめ」への対策
• 複数の権威DNSサーバーを配置...
Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 13
でも…その分コストは上がる
• 権威DNSサーバーを複数置いた場合、それらは
全て同じ応答を返さなければなら...
Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 14
「ルートサーバーのIPアドレスを
変えることが⼤変」への対策
• 根本的な対策はない ⇒「運⽤でカバー」
–...
Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 15
「反復検索しなければいけない」
への対策
• 反復検索⽤サーバーの導入
– 反復検索をそのサーバーに依頼
–...
Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 16
でも…混乱する人多数
• 反復検索⽤のサーバー(キャッシュDNSサー
バー)も権威DNSサーバーと同様に「D...
Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 17
「親の権威DNSサーバーへの
委任情報の登録が必要」への対策
• DNSが生まれ持った、避けられない宿命
•...
Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 18
レジストリゆえの宿命
• レジストリは1つのゾーンにつき1つのみ
– レジストリ・レジストラモデルの導入
–...
Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 19
過去のしがらみと
設計上の弱点
Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 20
過去のしがらみ
• 最初のDNSが誕生したのは1983年
– RFC 882/883
• 現在のDNSが誕生...
Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 21
設計上の弱点
• 時代背景や設計当時の事情などから来る、
さまざまな設計上の弱点が存在する
• プロトコルの...
Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 22
今日取り上げる項目
• 委任先(NS)を名前で指定している
• データをプッシュするしくみがない
• データ...
Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 23
NSを名前で指定している
• DNSでは委任先を名前(NS)で指定する
– 例: example.jp. I...
Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 24
鶏卵問題
1. example.jpの権威DNSサーバーに到達
するためには、ns1.example.jpの...
Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 25
解決:グルーレコードの導入
• NSを応答する時、該当する名前に対する
IPアドレスを「グルーレコード」とし...
Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 26
グルーレコードの特性
• NSで指定された名前が内部名(in-
bailiwick name)である場合にの...
Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 27
外部名の方がいい?
• 外部名の場合、鶏卵問題がそもそも起こらない
⇒ グルーは存在しない
– 例: exa...
Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 28
NSに外部名を指定するリスク
• 「私は外部名で指定したゾーンを100%信用し
ます」ということを意味してい...
Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 29
外部名の場合の名前解決手順
• NSが外部名だった場合、現在取り掛かっている
名前解決をいったん棚上げして、...
Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 30
NS設定内容の相互依存
• NSの設定内容が互いに依存し合っている
– 例: example.jp. IN ...
Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 31
外部名の取り扱い
• そもそもns1.example.comのIPアドレス
を、comゾーンを管理していない...
Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 32
参考: かつて⾏われた
外部名による攻撃
• CERT Advisory CA-1997-22 BIND
–...
Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 33
でも、考えてみたらグルーなんて
そもそも必要なかったんじゃ?
• そもそも「名前情報を委任する先を名前
で指...
Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 34
DNS最⼤のトラブル要因の一つは
こうして作られた
• Paul Mockapetrisさん(RFC 103...
Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 35
データを取り消すしくみがない
• 権威DNSサーバーでいったん公開した
データを取り消す(revokeする)...
Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 36
DNSはオペレーションミスに冷たい
• 間違ったデータを公開してしまった場合、データを修正
してから古いデー...
Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 37
データをプッシュするしくみがない
• 権威DNSサーバー側からキャッシュDNSサー
バーに対し、データを能動...
Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 38
DNSはデータの更新に冷たい
• 「このデータは更新されたから、キャッシュに残ってい
ても新しいのに替えてね...
Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 39
キャッシュの有効期限を
絶対時刻で指定できない
• DNSプロトコルではそもそも絶対時刻を
使⽤していない
...
Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 40
DNSは切り替えがルーズ
• データ公開時に「このキャッシュが有効なのは
○年○月○日○時○分○秒まで」とい...
Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 41
ユーザーがキャッシュを
制御するしくみがない
• ユーザー(クライアント)がキャッシュDNS
サーバーのキャ...
Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 42
DNSはユーザーにも冷たい
• 「元のデータがもう更新されているからすぐに
読み直してちょ」という機能がない...
Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 43
主な通信プロトコルがUDPである
• TCPと比較して発信元IPアドレスの詐称が
容易である
• これを悪⽤...
Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 44
DNS reflection
(amplification)attack
TXT XXXXX・・・・・
:
...
Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 45
キャッシュポイズニング
(図はhttp://jpinfo.jp/topics-column/013.pdf ...
Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 46
「512の壁」が存在する
• 伝統的なDNSの仕様では通信プロトコルとして、
UDPを⽤いる場合のDNS応答...
Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 47
フォールバックはトラブルの素
• フォールバックは遅い
– 原則として一度UDPで試し、データの切り詰
めを...
Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 48
フォールバックはトラブルの素
• 知識不⾜などにより、権威DNSサーバーの
53/tcpがファイアウォールな...
Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 49
で、「512の壁」は
そもそもどうしてできたのか
• DNSは「1980年代のネットワーク品質」
と「198...
Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 50
「512の壁」は
どうしてできたのか(続き)
• そのため、
1. IPヘッダ(20 オクテット)とUDP ...
Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 51
ちなみに…
• 1999年に標準化されたEDNS0では「ネット
ワークの信頼性やコンピューターの処理能⼒が
...
Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 52
IDが16ビットしかない
• DNSでは、パケットを識別するためのID
(問い合わせと応答には同じIDが割り...
Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 53
キャッシュポイズニングが
成⽴する確率
IDPortN
WR
PS
××
×
=
R: 攻撃対象1台当たりに...
Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 54
せめて、32ビットに
しておいてほしかった…
(「実践DNS」118ページより引⽤)
Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 55
応答の正当性を検証するための
しくみがなかった
• DNSには、応答の正当性(本当に正しいこと)
を受信者が...
Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 56
後付けで追加されたDNSSEC
• そのことが問題とされ、偽造されたものである
と受信者が判断するための機能...
Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 57
で、「DNSSECをdisってみる」
• …については、また今度機会があれば、、、
• 期待していた人、ごめ...
Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 58
基盤技術であるがゆえの
運⽤上の問題
Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 59
取り上げる項目
• 数多くの機能拡張が逐次的に実施された
• 実装依存な事項が多い
• 数多く存在する「運⽤...
Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 60
数多くの機能拡張が⻑年に渡り
逐次的に実施された
• 基盤技術であるDNSはRFCの数が非常に多く、
かつそ...
Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 61
数多くの機能拡張が⻑年に渡り
逐次的に実施された
• そのため、ある技術の全貌を知るために
は数多くのRFC...
Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 62
実装依存な事項が多い
• 細部の動作の具体的な仕様が定義されて
おらず、実装依存となっている事項がか
なり多...
Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 63
数多く存在する「運⽤でカバー」
• このような状況からDNSには「運⽤でカ
バー」している(する必要がある)...
Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 64
新しい技術を追加導入しにくい
• 既に運⽤されている基盤技術に新しい技
術を追加導入する場合、既存のものに影...
Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 65
フレッシュな技術者が
なかなか入って来ない
• このような状況からか、DNSを志すフレッ
シュな技術者がなか...
Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 66
最後に…
• というわけで、DNSを色々とdisってみました
• 今日取り上げたほとんどの項目には「現時点に...
Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 67
ありがとうございました!
「DNSトリビア(出張版)」に
続きます
Upcoming SlideShare
Loading in …5
×

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

Related Books

Free with a 30 day trial from Scribd

See all

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トリビア(出張版)」に 続きます

×