1. DNS/毒盛/キャッシュサーバ
Contents
2. キャッシュサーバの動作
2.1. 答えがキャッシュにあるか
2.2. 問い合わせを送る
2.3. 自分が送り出した問い合せに対する返答であるかを確認する項目
- UDP packet としては「受信IPアドレス」が一致しているのは当然の前提です。
- 送信元のIPアドレスとポート（ポートは５３のはず）
- 宛先ポート番号（自分が送り出したポート,かつては53固定だったことも）
- transaction ID (16bit)
- 問い合せ (query string, レコードタイプ）
そして、偽返答が正当な返答よりも先に到着するという条件も必要になります。
2.4. 受け入れてよい返事かどうか
キャッシュに保持されるための条件は別です。
- 問い合せに対しての返事であることが確認できても、キャッシュされるとはかぎらない。
2.4.1. in bailiwick 検査
権限外の名前に対するレコード（RRSet）は捨てられるべきである。
- root サーバ情報をつけてくるサーバはよく見かける。
2.4.2. キャッシュ上書きの条件も
同じラベルとレコード（タイプ）がキャッシュにあるときに上書きするか、捨てるかの判断が重要である。（RFC２１８１など）
2.5. 別の返事で上書きされないか
せっかく入った(キャッシュされたレコードが）別の問い合せの返答ですぐに上書きされるのでは、毒として有効とはいえない。
2.6. キャッシュされても使われるか
キャッシュサーバが返事をするときに、どういう風にキャッシュを利用するか。
- RFCでは一例としては書かれていても、そのとおりに動作すると問題を引き起こす。