## page was renamed from DNS/1/NS/キャッシュ内のNSレコード == キャッシュ内のNSレコード == <> 「あるゾーン」についてのNSレコードがキャッシュにあるか、ないかについて考察する。 　　あるとした場合、その由来はなにかも併せて考える。 1. キャッシュ内に当該ゾーンのNSレコードは存在しない (しかし、上位ゾーンのNSは存在するはず） 2. 上位ゾーンから受け取った委譲NSレコードセットが存在する 3. ゾーンの（権威ある）サーバから受け取った(authority section からの）NSレコードセットが存在する 4. ゾーンの（権威ある）サーバから受け取った answer section の NSレコードセットが存在する 　　３、４ が区別されているかは実装依存だし、2,3 が別個に保持されるかも実装次第だ。-- ToshinoriMaeno <> [[DNS/毒盛/NS毒盛/対策/zone cutsの非存在]] == 返答との優先関係 == それぞれの場合に、[[DNS/NSレコード/返答中のNS]]を受け取ったら、どうすべきかを考える。 原則はキャッシュにあれば、上書きしないのが安全なのだが、現状の多くの実装はそうしていない。 毒の排除のためには キャッシュに保存すべきかどうかの判断が重要である。-- ToshinoriMaeno <> [[DNS/毒盛/NS毒盛/対策/zone cutsの非存在]] キャッシュを上書きして問題がないか、上書きする方が都合がいいか、などのトレードオフも検討する。 == 毒盛の可能性 == Ranking が毒盛防止には役立たないことをはっきりさせる。 　以下は整理中のテーブル　-- ToshinoriMaeno <> キャッシュ中にNSレコードが存在するか --: なし De: 委譲NS, Au: 権威NS, An: Answer NS 受け取る返答の区別： 1. NS返答(Answer Section): 権威サーバを知っていないとしたら、偽（不正）返答である。 (親子同居を考慮する必要がある） 以下はすべて Authority Section 内の NS レコードである。 2. 本来の委譲（委任）: (Answer Section なし）; 上位のゾーンサーバからの委譲返答 3. 委譲を確認する： (Answer あり) （オレオレ）権威をもつゾーンサーバであることを確認するために返すNS。　 4. NS移転を示す： (Answer の有無は不明） （オレオレ）権威をもつゾーンサーバがNS移転、追加を示すために返すNS。 5. 問い合わせ削減用： （Answer あり） ゾーンサーバが効率改善のためにおまけとして付ける。 3 と区別がつかない。 6. 余計なお世話： (Answer なし） キャッシュ兼用サーバがキャッシュされた（権威を持たない）データ（多くは上位ゾーン）を返す。 NXDOMAINに付随するNSレコードもあるようだが、どう分類するかは未定。 受け取ったときの対応 ? : あり得ない返答（毒か親子ゾーン同居か） X : 捨てられる、 ◯： キャッシュ上書き ---- NS query の返答 ||返答＼キャッシュ||--|| 上位委譲 || 自己権威 || NS Ans || || 1 NS 返答 || 偽装・同居 ||NS Ans|| NS Ans|| ◯ An|| || 2 委譲返答 || 委譲 ||Lame ||◯||X || その他のケースの分は破棄 ---- A レコードを問い合わせたときの返答 (Authority Section のNSレコードRRSet) Answer Section なしの場合　（NXDOMAIN返答などは別途考察） ||返答＼キャッシュ||--|| 上位委譲 || 自己権威 || NS Ans || || 2 委譲返答 || 委譲 ||Lame ||◯||X || Answer Section ありの場合の Authority Section 内 ||返答＼キャッシュ||--|| 上位委譲 || 自己権威 || NS Ans || || 3 権威確認 || 偽装? ||Au||◯||X || || 4 移転通知 || 偽装? ||移転? ||◯ ||X || || 5 効率向上 || 偽装? ||? ||◯ ||X || || 6 ？？？ || 偽装? ||? ||◯ ||X || Authority Section から取り入れたNSレコードはAnswer のものより優先度（rank) が低いはず。 [[DNS/リゾルバ/動作例]]