1. DNS/委譲
DNS/delegation 委任とも言われます。間違いの多い部分です。
/rootserver /ゾーンカット /変更 /親子のNSレコードを一致させる |
委譲の誤り DNS/lame_delegation DNS/ゾーン/設定/誤委譲 DNS/委譲/変更
1.1. ドメインの委譲(委任)
ドメイン名空間を分割して管理するための仕組みが「委譲・委任」です。
DNS の世界は全体として「木構造」をしています。 各DNSゾーンサーバは自分の担当しているゾーン(部分木)の一部(部分木)を 他のDNSゾーンサーバに委譲(delegate)できます。
ドメインの登録(取得)はすんでいるものとします。
1.1.1. DNSゾーンサーバを動かす
担当するゾーンに対する問い合わせに責任をもつサーバを動かします。(RFC2181)
DNS資源レコードDNS/SOAレコードとDNS/NSレコードを含みます。
あるいはゾーンサービスを提供している業者と契約して、ゾーンを作成します。
- 共用DNSサービスは使い方をあやまると簡単にドメイン名ハイジャックされます。
1.1.2. ドメインを委譲してもらう
ゾーンサーバを動かしただけでは誰も問合せに来てくれません。
上位階層(親サーバ)にNSレコードを../登録してもらわなければなりません。
- 通常はレジストラ(JPでは指定事業者)を通します。
これがドメインを http://D/run-server.html#delegation 「委譲してもらう」 ということです。
1.1.3. 委譲のトラブルを減らす方法
- 登録されたサーバはすべて動かすこと
- 参照する側から見れば、プライマリ、セカンダリの区別はありません。
http://D/run-server.html 委譲してもらった名前でサーバを動かすこと
- 勝手に名前を変えてはいけません。
- サーバにはドメイン内の名前を付けること。(DJB流)
(子)サーバはできるだけ自ドメイン内におくのが安全です。 DNS/グルーレコードに関係するトラブルをさけるためです。
%dnsq a qmail.jp a.dns.jp 93 bytes, 1+0+1+3 records, response, noerror query: 2 qmail.jp authority: qmail.jp 86400 NS a.ns.qmail.jp additional: a.ns.qmail.jp 86400 A 131.112.32.6 additional: a.ns.qmail.jp 86400 A 218.44.237.137
DNS/逆引き設定も同様です。 (クラスレス委譲の逆引きの設定をちゃんと理解できたら、入門は卒業でしょう。)
お勧めの設定法も読んでください。
jp 直下のドメインの約 40 % が「正引きの委譲」で間違った設定をしていると推定しています。 DNS/ドメイン委譲の不良
1.2. 間違い
DNSのよくある間違い 伊藤 高一 DNS Summer Days 2012
正しい委任とは
1. 親がNS RR(とglue)で委任を提示している先のネームサーバがそのゾーンのauthoritative answerを返す。 2. 子がNS RRでauthorityの所在を主張しているネームサーバがそのゾーンのauthoritative answerを返す。 3. それぞれのネームサーバが同じ応答を返す。 4. キャッシュ上のデータを考慮しても、これらが成立する。
親が委任しているサーバを A, B としたら、A, B の返事がauthoritative であり、 返答が一致していること。
- A, B の返事に含まれる A1, A2, B1, B2 の返事が authoritativeであり、A, B の返答と一致していること。
- 条件 4 は満足させられるとは限らない。(矛盾すると困るのだが)
authoritative answerとはなにか、が問題か。
重要なのはlame delegation にどう向き合うかである。(定義が問題だとしても)