MoinQ: DNS/1/NS/出現場所

DNS/1/資源レコード/NS/出現場所

1. NSレコード/出現場所

RFC 1034, 1035 ... ゾーンファイル　親、子

2. ゾーン内

DNS/RFC/1034/4.2#A12

ゾーンを構成しているデータ中では、NS RRs は 
  ゾーンの最上位ノードについている（権威がある）か、
  ゾーンの底部のカットにある(権威はない)かであり、
中間にはあらわれない。 

ゾーンの根元（ゾーン名）に付随するNSレコードはゾーンの権威をもつサーバを確認するための資源レコードである。

• （このNSはNS移転情報としても使われることがあるが、規程された機能ではない。）

ゾーンの根元ではないノードに対するNSレコードはゾーンカットを示す資源レコードである。（委譲を示す）

• そのノード（以下）は別のゾーンに所属することを示す。(当該ゾーンとしては末端に位置するはず） このNSレコードの指す先に付随するA（AAAA)レコードが存在することもある。
  • その場合、そのAレコードは自ゾーンが権威をもつレコードではない。

3. DNS返答中のNS

/委譲返答や/遷都情報、ただの案内(余計な情報:上方参照、案内）、...　偽返答や間違い返答もある。

3.1. ゾーン同居

親子ゾーンが同居していると、ゾーンの根元でもなく、末端でもないノードに対してNSレコード Answerが返ることがある。

• このノードは実際には委譲された子ゾーンなどに対するものである。 委譲を確認することはできないため、SOAレコードを確認することが望ましい。　

[例] cz, nic.cz が同居しているccTLD/czでは、子の nic.cz NS 問い合せに対して、 answer section が返ってくる。

4. キャッシュとNSの関係

NS RRSet の選択と保存方法など。　glue も関係するか。　（キャッシュにあれば、上書きしないのがいいと思うが、多くの実装はそうなっていない。）

• 確認のために上位に問い合わせ直す実装もあるようだ。

5. DB

レジストラなどのDNSサービス業者での設定ファイル（GUIで設定するものが多い）

• NSを設定させない業者もあるとか

妄想

6. 間違った使い方

lame delegation, 余計なAレコード、 ...

7. 毒盛

攻撃方法も（出現場所によって）名前を使いわけるべきだと考える。

"node re-delegation attack" : 偽遷都情報注入による攻撃

単なる delegation attack : 偽委譲返答注入による攻撃

偽情報も多岐に渡るがNS関係が一番狙い易い。

8. 毒盛対策

キャッシュにある情報は上書きしないのがよい。

＠SIG@