## page was renamed from DNS/毒盛2014/多世代ゾーン同居 ## page was renamed from DNS/毒盛再考/多世代ゾーン同居 == DNS/毒盛再考/多世代ゾーン同居 == 多世代ゾーンをおなじサーバでサービスしている場合に 　そのサーバーが一番子孫側の場合、「毒盛されやすい状況」であることが判明しています。 　　では、一番祖先側だったらどうでしょう。　[[ccTLD/au]] などで見られます。 <> <> == 結論 == {{{ 多世代ゾーンは毒盛の危険を増やす }}} [[/NS名で分類]] jp TLD ゾーンの NS には [a-g].dns.jp という名前が使われています。　[[watchNS/jp]] [[watch-zone/jp]] 　これらは jp の子ゾーンである dns.jp ゾーンに所属する名前です。 (毒盛されやすい設定） 親子ゾーン同居（子ゾーン内の名前をNSにもつ）の危険性について、 === パンドラの箱 -1- では === 以下のようになっています。 http://www.e-ontap.com/dns/endofdns.html 前提： {{{ tld から sld.tld が委譲されているが sld.tld ゾーンが tld ゾーンと同じサーバにある場合、 }}} {{{ 2. 親子ゾーン同居 (世代間同居)への毒入れ a) 子ゾーン内の存在しない名前の問い合わせに対して、親が否定応答を返してしまう b) 孫ゾーン内の名前の問い合わせに対して、親が子を飛び越えて孫への委任情報(NS+A)を返してしまう(ex. www.foo.bar.internot.jp) ... }}} 同居しているホストの名前がなんであっても関係ない、というのがポイントです。 [[/さくらでの例]] a) の否定応答が親の返答か、子の返答かは分かりませんが、毒が入るかどうかの論点にはなりません。 どちらであっても、子ゾーンのNSに毒をいれられます。 　（子のNSはキャッシュにはないと想定しているので、親に問い合せているということでしょう。） 「親が子のNSを応答せず」否定応答を返す。「」がポイントでしょう。-- [[tss]] <> 　　否定応答を返しているのは、実際には（権威があるのは）子なんですが、キャッシュ側は親だと思っている。　-- ToshinoriMaeno <> b) の返答を返すのも親なのか、孫なのかは関係ありません。　（いきなり孫がでてきますが、祖先と孫の同居話ではない） この場合に毒を入れ易いのは子ゾーンのNSです。　（子や孫のNSはキャッシュにはない前提で。親に問い合せているのでしょう。） 　こっちはNXDOMAIN 返答でなくとも、毒盛に使えるという例になっています。（すばらしい） 　　孫ゾーン内の存在する名前に対する問い合せをするという発想は斬新！ (と思ったら、誤解だったらしい。） でも、孫は同居ではないですね。（確認） 　孫へのゾーン委譲： 単に子を飛び越しての委譲だと設定不良のような気もする。同居じゃないし。(想定環境の説明をお願いします。） 親子ゾーン同居で、孫ゾーンは別サーバということなら可能ですね。（これならいけるか） 　返答は親が子を飛び越えて返しているのではなくて、子が委譲返答（孫）をしているという解釈です。 でも、一度NSがキャッシュされたら、孫ゾーンの名前に対する連続攻撃はできなくなりそうです。（まだ、なにか足りない） -- ToshinoriMaeno <> 多世代同居（中間抜き）だと思ったのが、そもそもの誤解だったようです。 　おもしろいので、こっちのケースは自分で考えてみます。 [[/隔世同居]] === 同居の危険性も === jp TLD ゾーンの NS には [a-g].dns.jp という名前が使われています。　[[watchNS/jp]] 　これらは jp の子ゾーンである dns.jp ゾーンに所属する名前です。 (毒盛されやすい設定） それが親のゾーンであるjpのゾーンとdns.jp自身との両方のゾーンサーバとして指定されています。 　いわば親子のゾーンが同居している（同一のサーバでサービスされている）状態です。 こういう状態では、 dns.jp の NS レコードが表にでることはすくないというのがJPRSの指摘です。（キャッシュにも入らない: 毒盛しやすい設定） 　積極的に NS レコードを検索した場合だけが例外でしょう。　（私は疑問をもっているので、調査している） {{{ dns.jp の NS がキャッシュされることが少ないというだけではなく、 *.dns.jp という存在しないはず名前について問い合せると、NXDOMAIN 返答が返るというのもポイントです。 }}} つまり、 dns.jp NS を偽返答に入れてキャッシュさせることで、偽のdns.jp ゾーンを信じさせることが容易になりそうだということです。 -- ToshinoriMaeno <> 偽 dns.jp ゾーンを注入したときの効果を考えてみます。 == dns.jp zone 乗っ取りの影響の検討 == dns.jp NS xxx 偽NS RRSet をキャッシュさせられたときに、どういう影響があるかを考察してみます。 通常の利用ではキャッシュが dns.jp NS レコードを参照することはありません。 　（例外は dns.jp NS を問い合せられたときなどです。） つまり、これだけでは毒として作用しません。 dns.jp を乗っ取る目的は次のことにあります。 === jp zone 乗っ取り === dns.jp NS に毒を盛ったキャッシュサーバに a.dns.jp A を問い合せてみるとどうなるでしょう。 * a.dns.jp （正規のサーバアドレス）は jp NSサーバのglue としてキャッシュされています。 　　しかし、 A 問い合せの返答としては使われないことになっています。（2008? ~) * あるいは (glueかも）正規の a.dns.jp A の 消滅を待つということも考えられます。 　　このとき、Aが消滅するまで、毒が残るかどうか === 毒盛成功のケース １ === キャッシュサーバがキャッシュにない a.dns.jp A を外部に検索するなら、毒が有効となるでしょう。 このときの問い合せ先として dns.jp NS (毒の外部サーバ）が参照されます。 　偽サーバが偽 A (a.dns.jp) を返し、 A としてキャッシュされるでしょう。　（毒の活性化） この 偽A が glue を上書きするか、glueより優先されるのが BIND の欠陥でしょう。　（A と glue とは別個に管理する実装も存在しているようですが。） 次に jp サーバに問い合せる必要が生じた場合には この上書きされた毒情報が（glueとして）jp NSへのアクセスに使われるでしょう。（毒が作用したことになります） === 毒盛成功のケース 2 === glue A の期限がくるまで待ったとしても、毒NSレコード（dns.jp NS) が上書きされて解毒される可能性は小さいでしょう。　 　つまり、TTL時間だけ待つなら、正規のレコードは消えるため、毒盛は成功するということになります。 === 毒の効果が残る期間 === この毒がいつまで残る（有効）か、考えてみましょう。　[[DNS/毒盛/The Hitchhiker’s Guide to DNS Cache Poisoning]] 　a.dns.jp A が上書きされるかどうか。上書きされるなら、いつか。 Hitchhiker's Guide にはちょっと気になることが書いてあります。　NS+glue の優先度が一番高いという話 [[DNS/毒盛/BIND-trust-level]] に抜き出してある。 -- ToshinoriMaeno <> 上書きされるとしたら、実装の不良であると考えます。-- ToshinoriMaeno <> == dns.jp NS はキャッシュされないのか == 用心深いキャッシュであれば、 (unbound でもデフォルトはこうではない、と聞いた記憶がありますが） 　jpへの委譲返答をroot サーバから受け取ったものをキャッシュに入れるだけではなく、 　jpゾーンに問い合せ直して、（権威のある）NSとAを受け取るのではないかと考えます。 例えば、a.dns.jp A を確認したとすると、 [[watchNS/dns.jp]] のようになります。 　ここの dns.jp NS や A （glue 扱いしている可能性は残る）をキャッシュしているということはないでしょうか。 == それでも jp の毒盛は可能という説も == == 現状での結論 == {{{ 多世代ゾーン同居はあぶない。 }}} == あぶなくないケースはあるのか == [[/検討]] == root == [[DNS/毒盛再考/root-servers.net]] 毒盛できる根拠をきちんと理解していなかった。 root-servers.net は毒盛できる。でも、それだけでは root zone が毒盛できるということにはならない。 -- ToshinoriMaeno <>