## page was renamed from DNS/毒盛/SOA <> == DNS/毒盛/SOA == <> Kaminsky型攻撃に対する正規の返答は否定型[[DNS/返答/NXDOMAIN]]のことが多い。 　NXDOMAIN返答はAuthority SectionにSOAを返す。このSOAを毒の判別に活用する。 $ dnsq a zzzz.qqqq.qmail.jp a.ns.qmail.jp　(qmail.jpゾーンのゾーンサーバに問い合わせている） {{{ 1 zzzz.qqqq.qmail.jp: 90 bytes, 1+0+1+0 records, response, authoritative, nxdomain query: 1 zzzz.qqqq.qmail.jp authority: qmail.jp 2560 SOA f.ns.qmail.jp hostmaster.m.qmail.jp 1443943476 16384 2048 1048576 2560 }}} このSOAレコードからなにが分かるだろうか。 　「qqq.qmail.jpはゾーンではない。」 [[/キャッシュ]] 逆にSOAレコードを偽情報として送りこむとなにができるか、検討しておく必要がある。 通常は別の返答によって、上書きされてしまうだろうから、心配する必要はないのだろうが。 親子同居のケースでSOAのラベル（owner)がどういうドメイン名になるのか。（複雑w） [[DNS/1/資源レコード/SOA]] がどういう使い方をされるのかを知っておくこと。 -- ToshinoriMaeno <> == 最悪のシナリオ == キャッシュサーバがslaveサーバを兼ねていて、キャッシュにあるSOA情報を便りにmasterからzoneを得ていたりすると、 恐ろしいことになる。 だが、通常はSOAを含むゾーンファイル全体を保持しているはずだから、この心配はしなくてよい。 == NXDOMAIN返答の利用 == SOAレコードは毒盛撃退に利用できるし、そちらの方がずっと有益である。 　[[DNS/1/資源レコード/SOA]] -- ToshinoriMaeno <> 上にあげたzzzz.qqqq.qmail.jpをqmail.jp NSに問い合わせたときの返事にあるSOAレコードラベルから分かることは 　qmail.jp ゾーンには qqqq.qmail.jp以下の名前のゾーンは存在していない ということである。qqqq.omail.jpへの委譲返答（JPRSの委任インジェクション）が偽だと分かる。 キャッシュに保持された否定返答とSOAレコードがどう使われるか、調べる必要がありそうだ。 偽SOAの可能性も含めて。[[DNS/返答/NXDOMAIN]]　　[[DNS/1/ネガティブキャッシング]] -- ToshinoriMaeno <> == SOA活用の効果 == 存在しない名前・タイプを使った攻撃(Kaminsky-Mueller手法によるNS毒盛)は完璧といえるレベルで排除できる。 ただし、ロードバランサやドメインパーキング業者などでよく見られる「ワイルドカード設定された返答」 による毒盛対策には使えない。（NoError返答でAnswer Sectionがある場合） 　Authority Section NS を狙った攻撃に対する防御は必要だろう。Ancillary Attack対策 nonce付加によるNS問い合わせもやった方がよい。 unboundのharden-refferal-pathは毒盛対策としては不要だが、あった方がいい。 Ox020が不要かどうかは、他の毒盛の効果による。 **インジェクション対策にあげられた対策が鉄製の防具だとすれば、 SOAによる対策は鋼鉄製の装甲車だろう。 　機関銃くらいでは通らない。 親子ゾーン同居を避けるべき理由もなくなる。地域型JPドメインなども安全という主張ができる。 {{{ 　ただし、リゾルバー側の対策が必要なので、普及には何年かかるか。それが問題だ。 }}} サーバの監視が必要とか言っていたのも笑いとばしていい。 -- ToshinoriMaeno <> これがRFCにならなかった理由はわからないが、当時すでにSOA利用は一部には理解されていても不思議ではない。 https://tools.ietf.org/id/draft-weaver-dnsext-comprehensive-resolver-00.html == ワイルドカードありゾーンの問題 == ワイルドカードつきレコードがあると、randomドメイン名の問い合わせにもNXDomain返答が返るとはかぎらない。 　Answerが返ってきたということを使えないか、考えてみよう。 [[../wildcard]] 　　別ゾーンに分けられた問い合わせではなかったことが分かる。（ゾーン同居だと少し状況が異なる） 　系列ドメインの同居を考慮すると、Answerからのzone cuts確定には無理がある。 　　いったんzone cutsなしと推定する(gray)。 もし、delegationが返ってきたら、ゾーン同居の可能性を考慮して、確認のための問い合わせを送る。 ここはqname minimisationの出番か。 zone cut の非存在をもっと活用したい。 -- ToshinoriMaeno <> 中間ノードのdelegation返答が返ってきたら、確認のためのNS問い合わせをすればいいか。 -- ToshinoriMaeno <>