## page was renamed from DNS/サーバ/落とし穴 == DNS/サーバ/落とし穴 == さくらで使われているDNSサーバには問題があります。 　さくらDNS脆弱性は運用の問題だと理解したひとが複数いる。 前野はサーバの動作がDNS RFCに従ったものとは考えていない。-- ToshinoriMaeno <> == 問題とは == 親子（祖先、子孫）関係にあるゾーン（ドメイン）がおなじサーバでサービスされているときに、 * 若い（レベルの深い）ゾーンにある名前についての問い合わせがあると、 * 委譲がないにもかかわらず、 * 若いゾーンのデータ（と祖先で定義されたデータ）を答える。 この動作は世間でよく使われているBINDも同様らしい。 djbdns/tinydnsでもcdbファイルの作成時に検査を怠っていると発生する。 現状でこの問題発生をさけるには(ドメイン所有を確認しないなら）ふたつの方法が考えられる。 * amazon で行われているようだが、親子関係にあるゾーンは同居させない * 親子関係にあるゾーンは同一の所有者、登録者であることを条件にする。 -- ToshinoriMaeno <> サーバの動作に問題があるが、ただちに直せない事情があるのかもしれない。 　ひとつは委譲関係の確認に手間がかかるということらしい。 　　必要なことを手間惜しんでやらないというのは理解できないが、 　　　委譲関係の確認をいつどうやるか、という問題はDNS運用上は解決しておくべき問題だ。 委譲関係の確認がキャッシュサーバだけでは済まないことが分かったのだから。 == 環境 == 使われている権威サーバは一台だけです。 　権威のないはずのゾーンを（権威があると）返事するので、権威サーバとは呼びたくない。 リゾルバは関係ありません。 　徳丸浩の日記にある qmail.tokumaru.org をDNS検索してみてください。 それだけでは信じられないということであれば、beyoundDNSあてに連絡(tweet)してください。 問い合わせ先の権威サーバを指定する方法をご存知なら、別の例題もお見せできます。 == DNSサーバ側の問題 == あるドメインのためのゾーンがあったとします。 そこにサブドメインに対するゾーンがDBに追加されたとします。 親ドメインでは委譲はしていないので、このサブドメインはゾーンとしては認められません。（DNS） ところが、さくらで使っているコンテンツサーバはそれを権威あるゾーンとして扱っているようです。 　そこがひとつの問題なのです。あるいはゾーンではなく、親ドメイン内のRRとしているだけかもしれない。 　さくらの表現ではゾーンとありますが。 　それを確かめるにはこのような構成のゾーンファイルを作って、（BINDで）試すのがてっとり早い。 == 対策 == この実装上の問題を回避するひとつの運用手段として、 サブドメイン（とさらにそのサブドメインと）を同じサーバには同居させないというものが考えられます。 BINDコンテンツサーバもおなじ問題を抱えているようです。 おなじ所有者に属するドメインとそのサブドメインであれば、 このような動作をしても問題としては発症しないので、気付かれないでしょう。 しかし、所有者が異なるとハイジャックということになってしまいます。 サーバの不良と運用の間違いが重なることで今回の問題が起きたという見解です。 　（運用面では検査を怠ったというのもあります。） 委譲が行われていないサブドメインをゾーンとしてどこかのサーバに作ったとしても 問題にはならないと考えるのは普通です。 参照されることはないからです。 {{{ ただし、そのゾーンが親ドメイン（ゾーン)とおなじサーバでサービスされるとおかしなことになります。 }}} {{{ 登録させてはならないゾーンをDBに登録してしまっても、 　権威サーバが委譲のリンクを正しく追いかけていれば、不正なデータは使わないですむ。 というのが私の頭にありました。 現時点での多くのサーバソフトは使ってしまう。つまり、委譲検査はしていないということです。 }}} == 影響範囲 == [委譲されていないゾーン]?を権威があるとして答えるのは正しくない。 　このような実装のコンテンツサーバのことをなんて呼ぶのがいいか。 現実にはこのような実装が多いらしい。 BIND以外のものも調べなくてはいかんのか。 -- ToshinoriMaeno <> さくらからの連絡 {{{ とりあえず、Nominum社に確認することにしました。 基本的には委譲されていないゾーンは登録すべきでない＆削除すべきなのですが、 移転を考えると先に登録せざるを得ない状況もあります。 }}} 　さくらも状況を理解していないようだが、指摘しても、質問はかえってこないので、説明はあとにする。 -- ToshinoriMaeno <>