http://www5d.biglobe.ne.jp/%257Estssk/dns.htmlなどを参考に。
ドメイン名空間DNSが管理する空間全体を指す。ルートノードから広がる名前全体。ルートが上位あるいは親、末端が下位あるいは子の方向とする。
大文字小文字は区別されない。（が実装はそれを保存すべき、とも）
リソースレコードSOAレコードを始めとする個々の情報。
オーナー（対応ドメイン）、タイプ（A/NS/SOA）、クラス（今はINインターネットのみ）、TTL（有効期限秒数）、RDATA・資源テータ（目的のデータ）で構成される。
ノードリソースレコード（DNSでは木構造でいうリーフ＝葉もノードと扱う）やゾーン分割の根・節点。
ゾーンはそれぞれ固有の一つのノードをゾーンのルートとして持つ。
ラベルいわゆるホスト名。"" (BIND実装ではでは@で書き表すがDNSのプロトコル上では空文字そのもの)をゾーンのルートとして扱う。
63文字以下。BINDでいうホスト・ラベルと違うのは、ピリオドを許容しない点。
ドメイン名の表記ドメイン名を記述する時は、
完全な表記（いわゆるFQDN、絶対ドメイン名）は末尾に"."をつけてラベルのリストをつなげたもの。たとえば"www.example.com."（最後の.のあとに""空文字がある）
ローカルドメイン（＝文脈が属するドメイン）がわかっているときは相対表記。これは末尾に.がつかないので区別出来る。
特定のローカルドメインを指すのでなければルートから相対とみなす。
# とするとゾーンのSOAレコードに対応するドメインは例えば ".example.jp"と書くべきか？。
サブドメインあるドメインにの下位（子孫）に属するドメイン。直下のみを指す直接サブドメインという派生も。
委任あるゾーンの中から、一部のノードとその先のゾーンの権限を他者に渡すこと。NSレコードで実現される。
#このブログでは親ゾーンを
委任元、サブゾーンを
委任先と読んでいる。
NSレコードラベルでゾーンの切れ目を定義し、データでネームサーバを指定する。
NSレコードと必要ならグルーレコードは、小ゾーンを管理するネームサーバの応答と一致するべきである。
SOAレコードゾーンごとに一つ、ゾーン管理者のゾーン管理ポリシーを記述する。
CNAMEレコード別名＝エイリアスを定義する。ドメイン名に対して一つだけ定義できる。
ゾーンあるノードに対して、そのノードより下位に属する全てのノードの内、分割して委任していない部分。
ゾーンに含まれる情報は、
・分割して委任したゾーンを除く全ての権威レコード
・ルートノード自身に対応するレコード （上の一部）
・委任する先のゾーンのルートを示すレコード、
・委任する先のゾーンに属するが、NSレコードと委任先ネームサーバにアクセスするのに必要なレコード（グルーレコード）
権威データ・権威レコードThe authoritative data for a zone is simply all of the RRs attached to
all of the nodes from the top node of the zone down to leaf nodes or
nodes above cuts around the bottom edge of the zone.
ということで、NSやグルーレコードを含め、ゾーンに含まれうるレコード（＝リーフ）は全て権威があることになる。RFC2181 6.1で注釈、（NSレコードやグルーレコードはゾーンのリーフでもあるが）NSやグルーレコードを含まず、そのほか
ゾーンに含まれうるレコード（＝リーフ）は全て権威があることになる。
分割委任先のドメインに対応するレコードは全て権威をもたない。
DNS要求について要求するドメイン名と、要求するタイプ、再帰クエリ要求の有無や、現在ほぼ無意味なクラスなどパラメータを渡す。
DNS応答について回答セクション要求ドメインに完全に一致したレコード、およびCNAMEでのエイリアス先ドメインのレコードのリスト。
回答のAAビットフラグは、この内要求ドメインに一致したレコードが権威あるものであることを示す。CNAMEで解決したものについては何も言わない。
したがって、要求ドメインへの回答がCNAMEレコードなら、リゾルバはCNAMEのエイリアス先が権威あるDNSサーバ・信頼済みサーバからの回答かチェックする必要がある。
権威セクション応答するDNSサーバが、権威があると知っているゾーンについて記述するセクション。
例えばDNSコンテンツサーバは、要求されたドメインについて自身が権威を持っているなら（委任されていなければ）そのゾーンのルートゾーンに対応するNSレコード、委任済みで権威を持たないなら委任先のNSレコードを含めて返す。
追加セクションDNS応答の一部。NSやCNAME、MXなど、DNSサーバが応答を生成する時点で、RDATAがドメイン名を指し、将来リゾルバが問い合わせるだろうとわかっているとき、（気を利かせて）自身のキャッシュから追加して良い部分。また、全く知らないドメインを要求された場合、tldやルートゾーンなど、部分的なドメインに関する権威あるネームサーバについてキャッシュがあれば、これもここで返してよい。
注。
これを無制限に信頼してしまうと、キャッシュポイズニングの原因になる。信頼済みの例えばISPのフルリゾルバからの応答であったり、同じ権威DNSサーバが権威を持っている（再度問い合わせることになるだけの）レコードであれば信用してよいだろうが、インターネット上の特に信頼しているわけでないDNSサーバから返された追加セクションは無視すべきである。また、ネット全体に向けて公開するコンテンツサーバでは、どうせ無視される追加セクションは無効に設定してしまっても良いしそうすべきだ。(BINDの、addition-from-cache: no)。
DNSサーバの区別
フルリゾルバ再帰要求を受け付け、自分で全て解決して応答を返せるDNSサーバー。
スタブリゾルバ再帰要求を受け付けるが、単に他のフルリゾルバに転送・フォワードして、そこからの結果を返すリゾルバ。結果をキャッシュすることが主目的。
上記２つが主にキャッシュサーバと呼ばれるもの。
権威サーバー権威をもつレコードを保持するDNSサーバー。内部的にキャッシュも（暗黙に）持っていることになっている。
マスターサーバゾーンのマスターファイル（ゾーン設定ファイル）をもち、SOAレコードで指定される。セカンダリサーバはここに問い合わせて、ゾーン全体を更新する。ふつうNSレコードに載る権威サーバの一つ。
セカンダリサーバゾーンのマスターを持たない、ゾーン転送で受け取ったコピーのみを持つ権威サーバ。
以下はRFCに直接提示されていないが一般的ぽい呼称として、
コンテンツサーバ
ゾーンについての情報を持ち、（外から権威があるとみえるかはべつとして）自身が権威サーバであると認識しているDNSサーバー
たとえば、非公開のマスターサーバで公開されているスレーブサーバはSOAレコードのにのみ現れてNSレコードには現れない、など。
プライマリ・スレーブサーバ
それぞれマスター・セカンダリサーバに対応
キャッシュサーバ
リゾルバに対応。
posted by ko-zu at 23:47|
Comment(0)
|
TrackBack(0)
|
セキュリティ
|
|
