## page was renamed from DNS/1/委譲 = DNS/委譲 = [[DNS/delegation]] 委任とも言われます。間違いの多い部分です。 <> ---- <> 委譲の誤り [[DNS/lame_delegation]] [[DNS/ゾーン/設定/誤委譲]] [[DNS/委譲/変更]] == ドメインの委譲(委任) == ドメイン名空間を分割して管理するための仕組みが｢委譲･委任｣です。 DNS の世界は全体として「木構造」をしています。 各DNSゾーンサーバは自分の担当しているゾーン(部分木)の一部(部分木)を 他のDNSゾーンサーバに委譲(delegate)できます。 [[DNS/registration|ドメインの登録(取得)]]はすんでいるものとします。 === DNSゾーンサーバを動かす === 担当するゾーンに対する問い合わせに責任をもつサーバを動かします。(RFC2181) 　DNS資源レコード[[DNS/SOAレコード]]と[[DNS/NSレコード]]を含みます。 あるいはゾーンサービスを提供している業者と契約して、ゾーンを作成します。 　　共用DNSサービスは使い方をあやまると簡単にドメイン名ハイジャックされます。 === ドメインを委譲してもらう === ゾーンサーバを動かしただけでは誰も問合せに来てくれません。 　上位階層(親サーバ)にNSレコードを[[../登録]]してもらわなければなりません。 通常はレジストラ(JPでは指定事業者)を通します。 これがドメインを http://D/run-server.html#delegation 「委譲してもらう」 ということです。 === 委譲のトラブルを減らす方法 === * 登録されたサーバはすべて動かすこと . 参照する側から見れば、プライマリ、セカンダリの区別はありません。 * 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/逆引き設定]]も同様です。 (クラスレス委譲の逆引きの設定をちゃんと理解できたら、入門は卒業でしょう。) [[DNS/Recipe|お勧めの設定法]]も読んでください。 jp 直下のドメインの約 40 % が「正引きの委譲」で間違った設定をしていると推定しています。 [[DNS/ドメイン委譲の不良]] == 間違い == ------ '''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 にどう向き合うかである。(定義が問題だとしても)