DNS/毒盛/対策/SOA - moin.dnsq.info

1. DNS/毒盛/SOA

Contents

DNS/毒盛/SOA
最悪のシナリオ
NXDOMAIN返答の利用
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 2015-10-05 16:14:19

2. 最悪のシナリオ

キャッシュサーバがslaveサーバを兼ねていて、キャッシュにあるSOA情報を便りにmasterからzoneを得ていたりすると、恐ろしいことになる。

だが、通常はSOAを含むゾーンファイル全体を保持しているはずだから、この心配はしなくてよい。

3. NXDOMAIN返答の利用

SOAレコードは毒盛撃退に利用できるし、そちらの方がずっと有益である。

DNS/1/資源レコード/SOA

-- ToshinoriMaeno 2016-03-19 01:50:53

上にあげたzzzz.qqqq.qmail.jpをqmail.jp NSに問い合わせたときの返事にあるSOAレコードラベルから分かることは

qmail.jp ゾーンには qqqq.qmail.jp以下の名前のゾーンは存在していない

ということである。qqqq.omail.jpへの委譲返答（JPRSの委任インジェクション）が偽だと分かる。

キャッシュに保持された否定返答とSOAレコードがどう使われるか、調べる必要がありそうだ。

偽SOAの可能性も含めて。DNS/返答/NXDOMAIN　　DNS/1/ネガティブキャッシング

-- ToshinoriMaeno 2016-03-19 05:37:05

4. SOA活用の効果

存在しない名前・タイプを使った攻撃(Kaminsky-Mueller手法によるNS毒盛)は完璧といえるレベルで排除できる。

ただし、ロードバランサやドメインパーキング業者などでよく見られる「ワイルドカード設定された返答」による毒盛対策には使えない。（NoError返答でAnswer Sectionがある場合）

Authority Section NS を狙った攻撃に対する防御は必要だろう。Ancillary Attack対策

nonce付加によるNS問い合わせもやった方がよい。

unboundのharden-refferal-pathは毒盛対策としては不要だが、あった方がいい。

Ox020が不要かどうかは、他の毒盛の効果による。

**インジェクション対策にあげられた対策が鉄製の防具だとすれば、 SOAによる対策は鋼鉄製の装甲車だろう。

機関銃くらいでは通らない。

親子ゾーン同居を避けるべき理由もなくなる。地域型JPドメインなども安全という主張ができる。

　ただし、リゾルバー側の対策が必要なので、普及には何年かかるか。それが問題だ。

サーバの監視が必要とか言っていたのも笑いとばしていい。

-- ToshinoriMaeno 2016-03-29 16:00:11

これがRFCにならなかった理由はわからないが、当時すでにSOA利用は一部には理解されていても不思議ではない。 https://tools.ietf.org/id/draft-weaver-dnsext-comprehensive-resolver-00.html

5. ワイルドカードありゾーンの問題

ワイルドカードつきレコードがあると、randomドメイン名の問い合わせにもNXDomain返答が返るとはかぎらない。

Answerが返ってきたということを使えないか、考えてみよう。 ../wildcard
- 別ゾーンに分けられた問い合わせではなかったことが分かる。（ゾーン同居だと少し状況が異なる）
系列ドメインの同居を考慮すると、Answerからのzone cuts確定には無理がある。
- いったんzone cutsなしと推定する(gray)。

もし、delegationが返ってきたら、ゾーン同居の可能性を考慮して、確認のための問い合わせを送る。

ここはqname minimisationの出番か。

zone cut の非存在をもっと活用したい。

-- ToshinoriMaeno 2016-03-30 16:49:40

中間ノードのdelegation返答が返ってきたら、確認のためのNS問い合わせをすればいいか。 -- ToshinoriMaeno 2016-03-30 21:55:28