10分でわかる幽霊問題-事後資料

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

10分でわかる幽霊問題

dnstudy#03 / qpstudy#09 懇親会 LT2012年2⽉25⽇

森下泰宏@OrangeMorishita


10分でわかる幽霊問題

dnstudy#03 / qpstudy#09 懇親会 LT2012年2⽉25⽇

森下泰宏@OrangeMorishita

「わかった気になる」が正しい！by @tss_ontap


自⼰紹介（twitterのプロフィール）

• 46歳男性。JPドメイン名の中の⼈。DNSとの付き合いも早20年超。「いかにわかりやすく技術情報を伝えるか」が最近の課題。既婚。修⾏僧（⻘組）。太⽥裕美さんファン。どんどん深⼊りする因果な性格。某少⼥マンガの若い⼆⼈の⾏く末に超やきもき。ツイートは私の個⼈的⾒解であり勤務先や関係団体の公式⾒解とは異なることがあります。


幽霊問題（脆弱性）とは？• 2012年2⽉8⽇に中国・清華大学のHaixin Duan

（段海新）⽒らのグループによって発表された論⽂「Ghost Domain Names: Revoked Yet Still Resolvable」で報告– その前⽇にISCが「BIND 9全部だめぽ」と緊急発表

• 親（上位）ゾーンにおける委任情報（NSレコード）の削除後も⻑期にわたって、名前解決可能な状態に仕向けることができる脆弱性

• 消える（なくなる）はずのものが残り続ける– Ghost Domain Name（幽霊ドメイン名）


どんな時に困るか？• フィッシングやボットネットの制御、マルウェ

アの伝播など、不正な目的で使われているドメイン名を強制的に使用不能にするのを妨害される可能性がある

• 不正に使われていたドメイン名を強制的に移転する際、移転を妨害される可能性がある

• ドメイン名を新規登録したら昔誰かが使っていたので幽霊つきだった（広域で再現させづらいが、可能性としては技術的にあり得る）


影響を受ける（幽霊が出る）• 論⽂発表時点におけるすべてのBIND 9• djbdns（dnscache）• Unbound 1.4.7以前• PowerDNS recursor• Windows Server 2008に付属のMS DNS• 数多くの公開DNSキャッシュサービス• 論⽂著者グループが調べた2万弱のオープ

ンリゾルバーのうち、約70％以上– 1週間幽霊をキープできたものの割合


影響を受けない（幽霊が出ない）• Unbound 1.4.8以降• MaraDNS• Windows Server 2008 R2に付属のMS

DNS• Google Public DNS


幽霊が出る場所• キャッシュDNSサーバーのキャッシュ中• 消えるはずのものが残り続ける

– 「亡霊」の⽅が近いかもしれない• 影響を受けるキャッシュDNSサーバーは

「haunted resolver」と名付けられた– haunted house: 幽霊（お化け）屋敷– haunted resolverは何と訳せばよい？

• 権威DNSサーバーには幽霊は出ない– 再帰検索要求の受付をオフにしておくこと！


幽霊が出る理由• DNSプロトコルの不備（明確に規定／定

義されていないため、実装依存となっている部分）を突いたもの– 幽霊が出る実装と出ない実装が存在する

• 背景にある重要な⼆つの事項– NSレコードの信頼度– キャッシュの更新ポリシー


NSレコードの信頼度• NSレコードは親・⼦の双⽅に存在する

– どちらのNSレコードを優先すべきか？• DNSのプロトコル仕様の明確化について

定めたRFC 2181では、⼦のNSレコードをより⾼い信頼度（trustworthiness）で取り扱うように規定されている

• そのため、現在のキャッシュDNSサーバーの実装では、⼦のNSレコードを優先的に使用する形が主流となっている


キャッシュの更新ポリシー• キャッシュDNSサーバーに既にキャッ

シュされているデータを置き換える（上書きする）際の条件・ポリシー

• こちらもRFC 2181の「信頼度」が関係• 既にキャッシュされているデータと同じ

信頼度を持っているデータを受け取った場合、データを置き換える（上書きする）かどうかは現在のDNSプロトコルでは定められておらず、実装依存となっている


幽霊が出る条件（の⼀例）• 前提1:親の委任情報が消される前に、その

ドメイン名が既にキャッシュされている– キャッシュされていない場合、幽霊は出ない

• 前提2:攻撃者が委任先ゾーンの制御を握っているという前提で…


幽霊が出る条件（の⼀例）• そのドメイン名がキャッシュから消える前に

「そのゾーン内の違う名前（Aレコード）」を検索させるように仕向ける– 新しいNSレコード（下記）の名前にすると確実

• ただし、その前にそのゾーンの権威DNSサーバー上のNSレコードを「NSの名前は違うが、その名前のAレコードのIPアドレスは今のものと同じ」状態に設定変更しておく

• …というのを、NSの名前を変えながら繰り返す• 詳しいことは元の論⽂＆最後に紹介する資料を

ご欄くださいませ


除霊の⽅法• 幽霊を⾒つけ次第キャッシュをクリアする

– ISCが推奨– でもどうやって⾒つけるの？

• 定期的にキャッシュをクリアする– 今のところ⼀番よさげ– でもISPとかだと結構大変だよね…

• 幽霊が出ない実装／サービスに取り換える– 次ページ参照


幽霊が出ない実装／サービス• Unbound 1.4.8以降

– 最新版を使いましょう• MaraDNS

– 「親のNS」を優先するのでお奨めできない– 権威DNSサーバーの引っ越しに悪影響が出る可能性あり

• Windows Server 2008 R2に付属のMS DNS– 「DNS cache locking」という技術を使っているらしい– MSのWebにホワイトペーパーがあります

• Google Public DNS– Googleに頼るリスク、毒⼊れのリスク、Akamaiがうま

くロードバランスしないなど、以前からの未解決の問題


Unbound 1.4.8以降ではなぜ幽霊が出ないのか

• UnboundもBINDと同様、同じ信頼度を持っているデータを受け取った場合データを置き換える（上書きする）

• ただし、置き換えたレコードのTTL値はそれまで持っていたものをそのまま使う（置き換えない）– この変更はそもそも「浸透問題」に対するより良い対

策のために、Unbound 1.4.8で導⼊されたもの– TTLは「キャッシュしてよい時間」なので、この動作は

RFCに違反していない• ただし、現在のUnboundではunbound.confで

prefetch:yesとしていると幽霊が出るので注意– 発⾒者: @hdais さん（開発元に報告、修正済）– 次回のリリースで修正される予定


この問題をもっと知りたい• この問題（幽霊問題）はいわゆる「浸透問題」と同根です• でも、浸透問題が起こる実装と幽霊が出る実装は⼀対⼀対

応ではありません• その理由やしくみを勉強することで、DNSの委任のしくみ

や関係する諸問題に関する深い理解が得られます• ぜひ論⽂を読みましょう（平易な英語で読みやすいです）

段海新さんの公式Web:http://netsec.ccert.edu.cn/duanhx/

• その前にこれ読むといいかもです（頑張って書きました!）「ghost domain names（幽霊ドメイン名）」脆弱性についてhttp://jprs.jp/tech/notice/2012-02-17-ghost-domain-names.html

• ⾊々適当にツイートしてますので、お気軽にフォローくださいませ– でも、趣味（修⾏）のことや某少⼥漫画のことも遠慮なくつぶやきますｗ


ありがとうございました！

@OrangeMorishita

10分でわかる幽霊問題-事後資料

Entertainment & Humor