「DNS浸透問題」は脆弱性だった！「幽霊ドメイン名脆弱性」

「浸透いうな！」という掛け声が一部界隈で有名な「DNS浸透問題（もしくは、DNS浸透いうな問題）」ですが、今年2月にDNS浸透問題の原因の一つとなっている現象と同じものに起因する新たな脆弱性が発表されました。 その名は「幽霊ドメイン名脆弱性(ghost domain names)」です。

一見、DNS浸透問題とは全く別の問題のように思える「幽霊ドメイン名脆弱性」ですが、それが発生する原因と状況をよく見ると、「あ！これってDNS浸透問題で言ってた話と同じ原因だよね！？」とわかります。 実際、後述する通り、幽霊ドメイン名脆弱性の発想をDNS浸透問題と組み合わせることで、他人のDNS引っ越しを妨害するDoS攻撃も可能になります。

そう考えると、問題発生原因を調べずに「DNSの浸透をお待ち下さい」で済ませてしまうのは脆弱性の放置であるという考え方もできそうです(*1)。

ここでは、幽霊ドメイン名脆弱性とDNS浸透問題のどこが同じでどこが違うのかを紹介します。 幽霊ドメイン名脆弱性そのものの詳細な解説は行いませんが、同脆弱性の発生メカニズムを理解することはDNSそのものの動作や仕組みを理解するために非常に有用なので、興味がある方はJPRSによる解説をご覧になることを強くお勧めいたします。

DNS浸透問題と幽霊ドメイン名脆弱性の違い

DNS浸透問題(*2)と幽霊ドメイン名問題は技術的な要素や挙動などは基本的に同一ですが、大きく違うのがシチュエーションです。

幽霊ドメイン名脆弱性

幽霊ドメイン名脆弱性は、フィッシングサイト、ボットネット制御、ウィルス/マルウェア伝播など、不正な目的で運営されているドメイン名を強制的に使用不能(差し押さえ)にした際に、それから逃れることが可能であるというものです。

こうしたドメイン名の差し押さえでは、親ゾーンから委任(NSレコード)を削除、あるいは強制的に変更するという方法がとられる場合があります。 たとえば、warumono-example.comという悪徳サイトがあった場合、.comを管理しているレジストリがwarumono-example.comのNSレコードを.comゾーンから削除することでアクセスを不可能にしたり、別のNSレコードを設定することで任意のユーザがwarumono-example.com閲覧時に別サーバへと転送します(転送の例としては、たとえばFBIが運営し警告を表示するサイト)。

.comゾーンからの削除ではなく別のNSレコードが設定された例として、先日閉鎖されたmegaupload.comの事例があげられます。 2012年3月現在、megaupload.comに関してWHOISで出力される権威DNSサーバ一覧と、実際に.comゾーンに設定されている権威DNSサーバの一覧が異なっています。 WHOISではMegaupload LimitedによるNSが記載されていますが、実際に.comゾーンでNSとして指定されているcirfu.netの登録者はFederal Bureau of Investigation(FBI)です。

whois情報

Registrant:
   Megaupload Limited
   P.O. Box 28410
   Gloucester Road Post Office
   Wan Chai, Hong Kong  00000
   HK

   Registrar: DOTREGISTRAR
   Domain Name: MEGAUPLOAD.COM
      Created on: 21-MAR-05
      Expires on: 21-MAR-14
      Last Updated on: 28-NOV-11

   Administrative, Technical Contact:
      Lam, Bonnie  domain@megaupload.com
      Megaupload Limited
      P.O. Box 28410
      Gloucester Road Post Office
      Wan Chai, Hong Kong  00000
      HK
      +852-3013-7707


   Domain servers in listed order:
      NS1.MEGAUPLOAD.COM 
      NS2.MEGAUPLOAD.COM 
      NS3.MEGAUPLOAD.COM 
      NS4.MEGAUPLOAD.COM 



dig情報

$ dig megaupload.com. ns

;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21092
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 2

;; QUESTION SECTION:
;megaupload.com.			IN	NS

;; ANSWER SECTION:
megaupload.com.		26611	IN	NS	ns6.cirfu.net.
megaupload.com.		26611	IN	NS	ns5.cirfu.net.

;; ADDITIONAL SECTION:
ns5.cirfu.net.		963	IN	A	107.21.224.156
ns6.cirfu.net.		963	IN	A	107.21.226.254

しかし、NSレコードというのは親ゾーンだけではなく、子ゾーン側にも存在しています。 しかも、DNSにおいて親と子のNSレコードは意味するものが異なっています。

親のNSレコードは「そのゾーンはこのサーバに委任しています」ということを意味しており、子のNSレコードは「私はこのゾーンの管理権限を持っています」ということを意味しています。

そして、DNSプロトコルでは、NSレコードは子ゾーンで設定されるものが権威を持ち、親ゾーンで設定されるNSレコードよりも高い信頼度（trustworthiness）で取り扱うように規定されています（RFC2181参照）。

しかし、子のNSレコードが有効なのは「親の（子のNSレコードよりも信頼度の低い）NSレコードで委任されている間」のみです。 キャッシュDNSサーバにおいてこの部分の取り扱いが不適切であった場合、つまり、親のNSレコードが削除あるいは変更された後も、（既に子ではなくなった）子から送られてくるNSレコードの内容を信じ続けてしまう状況が発生した場合、親のNSレコードを削除あるいは変更することで使用不能にしたはずのドメイン名が使用可能にさせられ続けてしまう可能性があります。

このように、幽霊のように存在しなくなったはずのドメイン名が有効であり続けるのが「幽霊ドメイン名脆弱性」です。

幽霊ドメイン名脆弱性そのものの解説は、JPRSに記載されている解説をご覧頂くのが良いと思います。

• JPRS: 「ghost domain names（幽霊ドメイン名）」脆弱性について

特に重要なのが「概要」に含まれる以下の部分です。

そのため、各キャッシュDNSサーバー側で親ゾーンの委任情報の状態を必要に応じてチェックし、もし親ゾーンが委任情報を削除した場合、当該ゾーンの委任先からの情報を受け取らないように、適切に実装する必要があります。

しかし、現在のDNSプロトコルでは親ゾーンの委任情報の削除の検出や、その後の処理における具体的な手法が明確に規定／定義されておらず、実装依存の事項となっています。

今回の脆弱性はこうした背景から、キャッシュDNSサーバーの実装／動作に起因する新しい攻撃手法が発見されたことにより、顕在化したものです。

RFC2181において、同じ信頼度を持つNSレコードに関するキャッシュ更新をどうすべきかが明確に規定されておらず、現時点では実装依存であるという点も非常に大きなポイントです。 JPRS解説文には以下のようにあります。

このような、既にキャッシュされているexample.jpのNSレコードと同じ信頼度を持つNSレコードをキャッシュDNSサーバーが受け取った場合、それを新しいものに置き換える（上書きする）かどうかは現在のDNSプロトコルでは明確に規定されておらず、実装依存の事項となっています。

恐らく、私の文章を読んだだけではわかりにくいと思うので、是非JPRS解説文をご覧下さい。

ISC BINDでの対応

世界で最も利用されているDNSサーバソフトは、ISCのBINDであるとされていますが、同ソフトウェアは幽霊ドメイン名脆弱性論文で脆弱性を抱えているとされた実装の一つです。 幽霊ドメイン名脆弱性が発表された後に、ISCが「DNSはセキュリティの拠り所にするものではない」とするコメントを出しました。

• ISC : Ghost Domain Names: Revoked Yet Still Resolvable

非常に大ざっぱに表現すると、「そういった脆弱性は確かに発生する。ただし、それはDNSプロトコルそのものに起因する問題であり、すぐには修正できない。緊急パッチを出す予定も現時点ではない。そもそも通常のDNSはセキュリティの拠り所として使えるように設計されていない。DNSSECを使え。」という感じの内容でした。

しかし、その後リリースされたBIND 9.9.0(修正が入ったのはrc3。2月29日に正式版がリリース)には幽霊ドメイン名脆弱性を回避するためのコードが含まれており、またリリースに向けて作業中のBIND 9.8/9.7/9.6のrc版にも、同じコードが含まれているようです(DNSOPS.jpメーリングリストより)。

また、公式な発言ではありませんが、JPRSからISCに対し、この問題の解決を促すためのプッシュも行われていたようです。 ( https://twitter.com/OrangeMorishita/status/179116153799577600 )

ISC BINDのCHANGESには、以下のようにあります。 幽霊ドメイン名脆弱性の修正であることは特に明言されているわけではなく、「バグを修正した」という扱いのようです。 「脆弱性である」と大きく取り扱ったテーマが、その修正であると公式には明言されずにバグとして修正されている点を不審に思うという感想もあります（「浸透いうな！」のtss_ontapさん曰く「カミンスキー問題も同様」だそうです）。

3282. [bug]  Restrict the TTL of NS RRset to no more than that
             of the old NS RRset when replacing it.
             [RT #27792] [RT #27884]

修正方法として採用されたのは、キャッシュDNSサーバにおいてNSレコードのキャッシュを更新するときに、TTLについては既にキャッシュされているNSレコードのTTL以上の値にしないという手法です。 この変更によって、親ゾーン及び子ゾーンのNSレコードのTTLが減算途中で大きな値に上書きされることがなくなるので、幽霊ドメイン名脆弱性は発生しなくなるものと思われます。 ただし、この変更によって、正常時であっても以前よりも委譲元(親ゾーンの権威DNSサーバ)への問い合わせ数が増える可能性があります。

DNS浸透問題

「DNS浸透問題」の原因の一つとして、親のNSレコードが変更された後も旧権威DNSサーバー（かつての子）から送られてくるNSレコードの内容を信じ続けてしまうために、「DNSが浸透しない」と表現される状態が発生する、という現象が報告されています。

本来は参照されなくなるはずの旧権威DNSサーバを参照してしまっているという状況は、幽霊ドメイン名脆弱性と同じです。

仕組みだけを見ると同じですが、状況が大きく違います。

まず大きく違うのは、DNS浸透問題ではドメイン名を登録している人が自分の意志で権威DNSサーバの移管(もしくは移転)を行っているという点です。 幽霊ドメイン名脆弱性の場合は、何らかの原因によりドメイン名が強制的に差し止めされるような状況を想定しています(政府当局による強制的な差し止め以外に、更新料不払いという原因もあり得ます)。 幽霊ドメイン名脆弱性におけるドメイン名登録者は、かつては正規のドメイン名登録者でしたが、何らかの理由によってそのドメイン名を使用する権利を既に失っています。

さらに違うのは不適切なNSレコードを参照させたいかどうかの意図です。 幽霊ドメイン名脆弱性の場合は、フィッシングサイト等を運営している主体が意図的に旧権威DNSサーバが参照され続けるように仕向けることを想定していますが、DNS浸透問題はドメイン名登録者が「早く切り替われ」と望んでいます。

そして、「早く切り替わらない」という顧客からのクレーム対応として便利な言葉であることから「DNS浸透をお待ち下さい」が重宝されているようです。

「つまり、言い訳？」とJPRSプレゼン資料(DNS浸透の都市伝説を斬る - ランチのおともにDNS (PDF)、6ページ)にも記述されています。

確かに「便利な言葉」なのだろうと思います。 で、この「便利な言葉」を不適切な引っ越し方法をしていることの言い訳に使わないようにというニュアンスを含むのが「浸透いうな」です。

幽霊ドメイン名脆弱性の話を聞いてから、JPRS資料の18ページ以降で解説している「浸透問題が起こりうる引っ越し方法」を見ると、DNS浸透問題と幽霊ドメイン名脆弱性が同じ構造であることがおわかり頂けると思います。

幽霊ドメイン脆弱性の影響範囲

「幽霊ドメイン名脆弱性」そのものは、現在正規に使用中のドメイン名が乗っ取られたりするようなものではなく、差し止めになったドメイン名を使い続けさせることが可能であるという部分の紹介が多いため、多少地味な脆弱性にも思えます。

しかし、実際には差し止めになったドメイン名だけではなく、更新されずにexpireしたドメイン名や、ドメイン名の譲渡や売買(金銭的な報酬を伴う譲渡)が行われた後も以前のドメイン名登録者が利用している権威DNSサーバが参照され続けるように仕向けることも可能です。 脆弱性を発現させる方法が「該当する環境において名前解決をさせ続けさせるだけ」であるため、キャッシュDNSサーバがNATやファイアウォールの内側にあり、インターネットに直接接続されていない場合であっても実現可能という「手軽さ」も特徴としてあげられます。

また、幽霊ドメイン名脆弱性の発想を悪用して、他人のDNS引っ越しを妨害(DoS攻撃する)ことも容易に可能です。 たとえば、Twitterにおいて「DNSが浸透しない」と言っている人を発見したうえで、その原因が旧権威DNSサーバからの古いゾーン情報の垂れ流しであった場合を考えます。 攻撃者は、多くの人々がそのドメイン名での名前解決をするようにそのドメイン名を含むURLを大手掲示板などに貼付けたり、そのドメイン名を含むURLをimgタグに書き込んだうえでWebページを作成して多くの人々に閲覧させるなど、多くの人々が名前解決を行うように仕向けます。 それにより、そのドメイン名に対する旧NSレコードのキャッシュが切れる前に更新されるので、「全然DNSが浸透しない」という状況を人為的に継続させるというDoSも可能になると考えられます。

古いBINDを利用されている方々は更新を

現在、多くのDNS実装(djbdnsは除外)では、幽霊問題以前に、古いNSによる更新問題も解決済みです。 そのため、現時点において「DNS浸透遅い」という発言はTTLを理解していないか、間違った手順でのDNS引っ越し作業と古いキャッシュDNSサーバの組み合わせによって生じているものと思われます。

DNS浸透問題の議論において「TTLを無視するキャッシュDNSサーバがある」という話が度々登場しますが、どのバージョンのどのキャッシュDNSサーバがTTLを無視する実装になっているのかという具体的な話を見たことがありません。 また、tss_ontapさんによる報告(ISPのDNSキャッシュサーバはTTLを越えてキャッシュを保持するか?)でも、TTLを無視するキャッシュDNSサーバの存在は確認されていません。 基本的に「そういうのがある」という表現ばかりです。

幽霊ドメイン名脆弱性の論文にある手法は、古いNSによる更新問題を解決したはずの実装(*3)の穴を攻撃するものであるといえそうです。 JPRSのランチセッションによると、そもそも古いNSによる更新問題を抱えたままの古いBINDがBIND 9全体の33％とあります。 幽霊ドメイン名脆弱性を回避することを含めて、古いBINDをご利用の皆様は更新することをお勧め致します。

最後に

幽霊ドメイン名脆弱性はDNS浸透問題と非常に密接に関わっています(そもそも「DNS浸透問題」とは何かという点に関しては曖昧さが残りますが)。

今回の「幽霊ドメイン名脆弱性」という脆弱性が発表されたことから、DNSの引っ越しを行った後に古い権威DNSサーバからゾーン情報が発信され続けているという運用ミスに対して「幽霊ドメイン名が発生しています」というクレームを入れやすくなるのかも知れないと今回思いました(*4)。

(*1) とはいえ「幽霊ドメイン名脆弱性」は、「ドメイン名の差し止め」という行為の一般化と無関係ではないので、それが脆弱性であるとして認められるという時代背景もあります。

(*2) 「DNS浸透問題」の原因と推測されている現象は単一ではなく、幽霊ドメイン名脆弱性と同根なのは、そのうちの旧権威DNSサーバからの情報を信用し続けてしまう場合に発生する状況です。 ここでは、その状況にフォーカスしています。 新たに登録されたドメイン名が設定完了後も反映されていないように見えてしまうという現象なども「DNS浸透問題」に含まれていますが、それは「幽霊ドメイン名脆弱性」とは違う仕組みです。

(*3) BIND 9.2.3で修正。BIND 9.2.2以前のバージョンで問題が発生。BIND 9全体の約33％が旧バージョンを利用していると推測されているようです。JPRSランチ発表資料 p.24-p.30参照。

(*4) 実際は差し止めになったドメイン名というわけではないので厳密に言うと間違った表現ではありますが。 あと、基本的なしくみが同じであることから、「浸透問題」を抱えているキャッシュDNSサーバーの実装では「幽霊ドメイン名脆弱性」も抱えている可能性が非常に高いです（詳細は省略しますが、「幽霊ドメイン名脆弱性」を抱えていても「浸透問題」を抱えているわけではありません）。

参考

• Network and IT Security Conference: NDSS 2012
• Ghost Domain Name: Revoked Yet Still Resolvable (in NDSS 2012)
• 浸透いうな！
• Internet Watch: DNSの「浸透問題」は都市伝説 - 正しいサーバー引っ越し法を解説
• DNS浸透の都市伝説を斬る - ランチのおともにDNS (PDF)
• Geekなぺーじ：なぜ「DNSの浸透」は問題視されるのか

おまけ

今回の記事で最も頑張ったのは図です(頑張ったからといって奇麗な図が出来たわけではないところが悲しいところですが)。 全て、イラストレーターでゼロから作りました。 特に苦労したのが、「DNSの浸透をお待ち下さい」と発言しているコールセンターのお姉さんです。 そもそもイラストレータの使い方もよくわかってないので結構苦労しました。

参考にしたのは以下の２冊です。 お姉さんの絵を書く方法は「Illustratorでもっと楽しくイラスト」の62-87ページです。

Illustratorではじめてのイラスト

Illustratorでもっと楽しくイラスト

文章も、いつもようにやたらと長いものを最初は書いていたのですが、この話題に関しては私がグダグダ書くよりも「JPRS: 「ghost domain names（幽霊ドメイン名）」脆弱性について」へのリンクを張る方が正確でわかりやすいことに途中から気がついて路線変更しました(と言いつつ、最終的に長い文章になってますがorz)。

で、「幽霊ドメイン名脆弱性」という凄くわかりにくい問題をどうやったら、わかった気になっていただいたうえでさらに調べる気持ちになれる文章を書けるかを悩んだところ、「イラストだ！」と思ったのでIllustratorを勉強しつつ描いてみました。

図が欲しいと思った時に誰かに頼むということができないわけで、こういう技術をコツコツと学習して積み上げるしかないわけなんですよね。

おまけ２

JPRSの方々が執筆されている「実践DNS - DNSSEC時代のDNSの設定と運用 -」は良い本だと思うので、DNS関連の話題に興味がある方々にお勧めです。

最近のエントリ

• Interop 2023のShowNetバックボーン詳解
• Interop Tokyo 2023 ShowNet取材動画
• 「ピアリング戦記 - 日本のインターネットを繋ぐ技術者たち」を書きました！
• 1.02Tbpsの対外線！400GbE相互接続も - Interop ShowNet 2022
• Alaxala AX-3D-ViewerとAX-Sensor - Interop 2022
• SRv6を活用し、リンクローカルIPv6アドレスだけでバックボーンのルーティング - Interop ShowNet 2022

過去記事

過去記事一覧