## page was renamed from DNS/リゾルバー動作/付加節のレコード
## page was renamed from DNS/リゾルバー/動作/付加節のレコード
## page was renamed from DNS/キャッシュサーバ/動作/付加節のレコード
## page was renamed from DNS/キャッシュサーバの動作/付加節のレコード
#acl ToshinoriMaeno:admin,read,write Known:read,write All:read
#pragma section-numbers off
== キャッシュサーバの動作/付加節のレコード ==
権威あるサーバからの返事の付加節(additional section)の扱いについて議論します。

=== RFC2181 第10節 ===
DNS(コンテンツ)サーバが行う付加節処理に関して RFC2181 第10節に説明があります。
　そこには 「NS, MX レコードの検索は付加節処理を引き起こす。それは__CNAMEレコードを含まない__。」とある。
　さらに NS レコード値が CNAMEラベルであったら、その A レコードは__含めない__。ともある。

=== キャッシュサーバでの付加節のレコード処理(提案) ===
　* CNAMEレコードに対応するものであれば、捨てる。
　* MXレコードに対応するものであれば、捨ててもよい。悪影響は軽微。
　* NSレコードに対応するものであって、glueであるなら受け入れる。
　　毒盛を警戒するのであれば、問い合わせ直す。(TCP queryもよい。）
------
DJB は djbdns の解説の中で、in bailiwick の情報はすべて信用するという立場です。
　当初から port randomization を行っているため、当時のBINDより偽情報に耐性があるからでしょう。

BIND は port randomization を行っていなかったにもかかわらず、in bailiwick 情報は受け入れるようです。
　ただし、CNAME の付加節は破棄している印象もあります。
それなら Kaminsky 型攻撃はいろいろな形で容易に成立します。

一方でBIND集団はtrust level という概念を持ち出して、キャッシュに受け入れるかどうかを決めるという
問題のある対応をしていました。

=== glue レコードの扱い ===
さて、glue レコードは delegation 時に付加節にあらわれる A レコードのうちの一部のものです。
真性の glue レコードと似非 glue レコードがあります。

真性の glue レコードとはそれを利用しなければ目的ドメインのDNS(コンテンツサーバ）に到達できないようなものです。
受け入れが必須の情報です。

これとは異なり、似非glue レコードはDNS 通信の負荷を削減するために利用されるにすぎません。
-----
キャッシュへの毒盛のターゲットとして狙われることの多いウェブサーバのIP アドレスはこの似非glue レコードとして
現れることが多かったために、glue レコードを区別することで毒盛を防ごうとする考えもありました。

しかし、真性の glue かどうかということがそんなに重要でしょうか。
　真性のglueであれば毒盛できないということであれば意味があるといえますが、そうではありませんから、
　真性 glue を区別することにはたいした意味はありません。

----
結局、DNS spoofing にたいする防御は応答の中身を調べることではなく、
偽パケットを判別できるようにすることだと言えます。その強化策のひとつがport randomization です。

DNSSECも一つの手段ですが、欠点もあり急速な普及は望めません。

DNS データ自身も設定間違いなどがあり、信頼性も十分とは言えません。
DNSを信用するのではなく、接続相手を確認するための手段を別途用意しておくことが一段と重要になることでしょう。