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

Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 1

DNSをあえてdisってみる

DNS周辺技術勉強会 #dnstudy 022011年10⽉29⽇

森下泰宏


私は誰?• ⽒名: 森下泰宏（もりしたやすひろ）

– 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の設定が互いに依存し合っている場合、名前解決ができなくなる（次ページ）


Sibling Glue• NSの設定内容が互いに依存し合っている

– 例: example.jp. IN NS ns1.example.com.example.com. IN NS ns1.example.jp.

• これは「sibling glue」と呼ばれ、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に誘導され、⼤きな騒ぎになった

• 脆弱性が存在した実装– BIND4.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 攻撃の準備











DNSキャッシュサーバTXT XXXXX・・・・・

：・・・・・XXXXX

Botnet攻撃者

権威DNSサーバ

攻撃対象のコンピュータのIPアドレスを騙って一斉にDNS問い合わせを行う

攻撃対象のコンピュータ

図2 DNS Amp攻撃

指令































DNSキャッシュサーバTXT XXXXX・・・・・

：・・・・・XXXXX

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通りしかない

• 現在のコンピューターやネットワークの能⼒からすると、ブルートフォースアタックに対する耐性が⼗分ではない

• カミンスキー型攻撃⼿法が⼤きな脅威となり得た理由の⼀つ


キャッシュポイズニングが成⽴する確率

IDPortNWRPS

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ってみる-事後資料

Lifestyle