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

Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 1
DNSをあえてdisってみる
DNS周辺技術勉強会 #dnstudy 02
2011年10月29日
森下泰宏
2016年12月5日追記：
この資料の記述には、既に古くなった箇所が存在するため注意が必要です。
また、2016年12月5日に最低限の修正をしています（資料中の⻘字部分）。
（修正内容：上位・下位を親・⼦（⼦孫）という記述に変更、スライド30の修正など）

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

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

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

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

本日の内容
• 第一部: DNSをあえてdisってみる
– DNSの欠点や弱点を知る
– 欠点や弱点を知ることでより良く付き合う
• 第二部: DNSトリビア（出張版）
– twitterで不定期に配信
– DNSについて意外に知られていないこと
– 知っていると得する（かも知れない?）こと
いわゆる「浸透問題」はこちらで取り上げます
イマココ

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

…の前に、念のために意識共有
―今日のタイトル「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

構造上の宿命ととられた対策

構造上の宿命（1）
• 根元の権威DNSサーバーほど負荷が集中する
• 親のDNSサービスが停止した場合、その⼦孫の
すべてのゾーンが利⽤できなくなる
– ルートサーバーやTLDのサーバーが落ちると⼤変
• ルートサーバーのIPアドレスはおいそれとは変
えられない
– インターネット上のすべてのキャッシュDNSサー
バーが持っている表（ヒント）に影響を及ぼす

構造上の宿命（2）
• 名前解決の際、各ゾーンの権威DNSサー
バーに対し反復検索をしなければならない
– 反復検索のコストは決して⼩さくない
– 時間もかかる
• 委任情報を、親ゾーンの権威DNSサー
バーにあらかじめ登録しておく必要がある

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

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

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

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

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

「親の権威DNSサーバーへの
委任情報の登録が必要」への対策
• DNSが生まれ持った、避けられない宿命
• ⼦ゾーンの委任情報を受け付け、自分の管
理する権威DNSサーバーへの登録・公開を
⾏う主体を、それぞれの階層ごとに導入す
る必要がある
– DNSプロトコルの外で実装する必要がある
• その役割を担当する組織を「レジストリ」
と呼ぶ
– つまり、レジストリが各階層ごとに必ず必要

レジストリゆえの宿命
• レジストリは1つのゾーンにつき1つのみ
– レジストリ・レジストラモデルの導入
– レジストリ間における競争
– 新しいgTLDの導入（ICANN設⽴目的の一つ）
• 特定のTLDへの負荷集中
– .com: 約9000万以上（世界全体の約4割弱）
– .jp: 約125万
• （以下、ここでは色々と自粛）
– 懇親会ネタ?

過去のしがらみと
設計上の弱点

過去のしがらみ
• 最初のDNSが誕生したのは1983年
– RFC 882/883
• 現在のDNSが誕生したのは1987年
– RFC 1034/1035
• 既に20年以上が経過
– さまざまな「過去のしがらみ」が存在する

設計上の弱点
• 時代背景や設計当時の事情などから来る、
さまざまな設計上の弱点が存在する
• プロトコルの改良や機能拡張、運⽤上の
工夫などにより弱点のいくつかはかなり
の程度カバーされてきたが、本質的な弱
点が解消されているわけではない

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

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

鶏卵問題
1. example.jpの権威DNSサーバーに到達
するためには、ns1.example.jpのIPア
ドレスを知らなければならない
2. ns1.example.jpのIPアドレスを知るに
は、example.jpの権威DNSサーバーに
到達できなければならない
3. 1.に戻る

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

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

外部名の方がいい?
• 外部名の場合、鶏卵問題がそもそも起こらない
⇒ グルーは存在しない
– 例: example.jp. IN NS ns1.example.com.
• ドメイン名ごとにレジストリに登録が必要なも
の（管理が必要なもの）が少なくて済む
– 内部名の場合
• ネームサーバーホスト名とそのIPアドレス
– 外部名の場合
• ネームサーバーホスト名のみ
• じゃ、外部名のほうがいいのか?
– そんなことはない！

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

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

NS設定内容の相互依存
• NSの設定内容が互いに依存し合っている
– 例: example.jp. IN NS ns1.example.com.
example.com. IN NS ns1.example.jp.
• このような設定をした場合、example.jp
とexample.comの双方のゾーンとも名前
解決ができなくなる危険性があるため注
意が必要
• 3つ以上の相互依存関係もありうる

外部名の取り扱い
• そもそもns1.example.comのIPアドレス
を、comゾーンを管理していないjpゾー
ンの権威DNSサーバーが教えていいのか?
– そして、教えられた側は使ってよいのか?
• 最近のキャッシュDNSサーバーの実装で
は、委任情報として外部名が送られてき
ても無視する（捨てる）
– 次ページ参照

参考: かつて⾏われた
外部名による攻撃
• 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に付属)
• デフォルト設定: レジストリにより設定変更可能

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

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

データを取り消すしくみがない
• 権威DNSサーバーでいったん公開した
データを取り消す（revokeする）ための
しくみが存在しない
• 間違った設定や不適切な設定をしてし
まった場合などに「い…今のはなし」と
いう設定（切り戻し）ができない

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サーバーのみであった）

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

キャッシュポイズニングが
成⽴する確率
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 より引⽤）
⼤きいほど
確率が⼩さくなる

せめて、32ビットに
しておいてほしかった…
（「実践DNS」118ページより引⽤）

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

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

で、「DNSSECをdisってみる」
• …については、また今度機会があれば、、、
• 期待していた人、ごめんなさい
• たぶんこれだけでおかわり3杯いけます(謎)

基盤技術であるがゆえの
運⽤上の問題

取り上げる項目
• 数多くの機能拡張が逐次的に実施された
• 実装依存な事項が多い
• 数多く存在する「運⽤でカバー」
• 新しい技術を追加導入しにくい
• フレッシュな技術者がなかなか入って来ない

数多くの機能拡張が⻑年に渡り
逐次的に実施された
• 基盤技術である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が入っている

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

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

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

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

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

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

ありがとうございました！
「DNSトリビア（出張版）」に
続きます

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

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (6)

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