= DNS/毒盛/対策/末永 =
以下にまとめられている。
  http://wp.kaz.bz/tech/2016/03/29/2109.html  SOAを利用したゾーン不存在情報を偽応答の評価に利用することについて。

[[/コメント]] 書き込み可能

<<TableOfContents()>>

攻撃手法はKaminsky-Mueller手法を使った偽委譲返答によるNS毒盛である。
　[[DNS/毒盛/Mueller手法]]

{{{
返答に付随するSOAレコードから得られる情報を利用して、
zone cut が存在していない場所を知り、それを委譲返答毒(*)の排除に使うものである。
　(*) JPRSは「委任インジェクション」と呼んでいる。

SOAレコード以外からもzone cutの非存在を確認できるが、ここでは扱っていない。

zone cut非存在は他の毒の排除にも利用できるが、今ここでは扱わない。
}}}

[[DNS/毒盛/対策/zone cutの非存在]]

== 防御方法について ==
=== 基本原理 ===

以下のロジックにより、DNSキャッシュサーバがキャッシュされていない偽応答を受け取った際、
事前にその偽応答があり得ないことを予知することができ、偽応答を無視することができます。
また、そもそもその偽応答に対応する問い合わせを行わないことができます。

{{{
コメント：単なる偽返答ではなく、偽の委譲返答(NS)を対象とした対策です。
　　以下の部分はやや混乱しているように思うが、どうコメントするかは未定

「キャッシュにない応答を受け取ったとしても」という意味でしょうね。

偽応答が返る問い合わせをさせないのは無理です。
}}}

 *「攻撃対象となっているドメイン名がゾーンではない」ことを事前にDNSキャッシュサーバが知っていることによって、
そのドメイン名に対するNSレコードを受け入れない（正当な回答と認めない）ことができる。
 * 事前に「その名前のゾーンは存在しない」ことを知っておくことにより、
そのドメイン名に対する問い合わせが発生した際にNSレコードを返さないことができる。
 * SOAレコードはゾーンカットされている点（=そのゾーンの頂点）にのみ存在することから、
ゾーンが存在する場合SOAレコードは問い合わせたドメイン名に対するものと一致する。
 * 問い合わせたドメイン名からSOAレコードで返されたラベル名までの間のサブドメインに対し
ゾーンが存在しないことを知ることができる。
 * ゾーンが存在しないことを知っていることにより、
上位のサーバに対する問い合わせを発生させずに問い合わせへの応答ができる。

=== 「ドメイン名がゾーンではない」ことを知る方法 ===
ドメイン名がゾーンではないことを知るために、NODATA(上記 正当な問い合わせの応答 2.）およびNXDOMAIN（同 3.）の際にAUTHORITY SECTIONに返ってくるSOAレコードの利用ができる。

{{{
 co.jpを問い合わせているわけではない。qname minimisationではco.jpを先に問い合わせることになる。
}}}
 * 例で co.jp を問い合わせている際に jp のSOAが返ってきているということは co.jp ゾーンが存在しないことを意味する。
 * 同時に co.jp に対する NSレコードがないことを意味する。
 * また 例えば example.co.jp について dig +norec a example.co.jp @z.dns.jp とすると jp の SOA が返ってくるが、このことから、example.co.jp ゾーン、および co.jp ゾーンの存在しないことを同時に知ることができる。

=== 「ドメイン名がゾーンではない」ことを知るタイミング ===
想定している攻撃手法は1度で成功する確率は非常に低いため、
1度目の問い合わせの時点でSOAレコードが取得されることによりゾーンが存在しないことを
DNSキャッシュサーバは事前に知ることができる。

{{{
事前ではなく、攻撃が届く前にくらいでしょうか。

最近始まったqname minimisationでゾーンカット探索を行うので、
そのときにもzone (cut)の不存在を知ることができます。
co.jpなどはそうなるでしょう。
}}}

攻撃に限らず通常の(間違った）問い合わせで発生する応答などからも同様にゾーンが存在しないことを知ることができる。

=== この防御方法の利点 ===
原理が単純であり対応が極めて容易である
    1度目の攻撃をそのまま防御に利用できる
正常な問い合わせや単なる間違いも含めて、正しいゾーン境界をしる機会が非常に多い

元々本来受け取っているデータを元にするため新たに通信量が増大するわけではない

{{{ 
評価をありがとう。
  対策として成立するかどうかを考えている段階でしたので、効率などは検討不十分でした。
}}}