パソコン実習室
アドレス検索 - DNSの話
≪　previous next　≫

Ⅲ．ゾーン

　ドメインの管理者はその権限と責任において、ホストやサブドメインの新設、撤去、管理、運用を行います。管理者の権限や責任の範囲はどこまでなのでしょう。

Ⅲ．１．委任とゾーン

　管理者はネームサーバーを運用して、自ドメインの名前解決(ドメイン名とIPアドレスの相互変換)サービスを提供します。管理者がカバーしなければならない範囲はサブドメインにも及びますが、サブドメインは必要があって分割した部分ツリーですから、そちら側の組織に管理を一任するのが一般的です。
※　ホスト(ドメイン)名とIPアドレスの変換を行うソフトウェアを総称してネームサーバーといいます。
　　ドメインネームサーバー、DNSサーバーとも呼ばれます。

　管理を一任する行為を委任と言い、委任された組織ではネームサーバーを設置して自ドメインの名前解決サービスを開始します。

分割し委任された範囲をゾーン(zone)と呼びます。
ゾーンとは、ドメイン名空間において自治管理される部分ともいえます。

　ゾーン内のホスト情報等(名前解決)は、そのゾーンの管理者がネームサーバーを立ち上げて管理する事になり、分割元の親のゾーンでは、委任先ゾーンのネームサーバーのみを管理すれば良いことになります。

　サブドメインとして分割しても委任しないことも可能です。その時のサブドメインのゾーンは分割元の親ドメインに属します。


Ⅲ．２．ゾーンとドメイン

　ゾーンとドメインの関係を、ある架空の組織(project研究所)で考えてみましょう。
project研究所は下記のドメイン名を取得しました。

project.ed.jp

研究所のネットワーク管理者は、ネットワーク構成について次のように考えたとします。
  • 主要な研究部門は Windows部門, Linux部門, Network部門 の3部門なので、それぞれをサブドメインとする。
  • Windows部門 と Linux部門 は自分で管理しよう。
  • Network部門 は大所帯なので、その部門の管理者に一任(委任)する。
その話を聞いたNetwork部門の管理者は次のように考えるかもしれません。
  • Webチームまでは手が回らないので分割し、管理はWebチームに委任しよう。
  • 他のチームは自分で管理しよう。

　こうして出来上がったproject.ed.jp研究所ネットワークの、ドメインと委任とゾーンの関係は次の図のようになります。

※　赤の二重線は、上位ゾーンから下位ゾーンへの委任を表わしています。

　管理者が把握・維持しなければならないのは自ゾーン内(および委任先ゾーンのネームサーバー)の情報に限定できるため、各管理者の保守範囲は次のようになります。
  • 【 project.ed.jp ゾーン : 研究所管理者の保守範囲 】
    Windows, Linux両サブドメインを含む、project.ed.jp ゾーン内のホスト情報。
    network.project.ed.jp ゾーンのネームサーバーの情報。

  • 【 network.project.ed.jp ゾーン : Network 部門管理者の保守範囲 】
    network.project.ed.jp ゾーン内のホスト情報。
    web.network.project.ed.jp ゾーンのネームサーバーの情報。

  • 【 web.network.project.ed.jpゾーン : Web チーム管理者の保守範囲 】
    web.network.project.ed.jp ゾーン内のホスト情報。
※　webチームは委任したサブドメインを持っていないので、ドメインとゾーンが一致しています。
　　通常はこうした形態が多いと思います。



Ⅲ．３．資源レコード

　ネームサーバーが扱うデータはゾーンデータと呼ばれ、複数の資源(リソース)レコードで構成されています。資源レコードには、ドメイン名、ホスト名、IPアドレス、ネームサーバー等の情報を記述しますが、資源レコードは扱う情報ごとに数種類あります。

　ゾーンデータはネームサーバー(再)起動時に読み込まれます。ネームサーバーは問い合わせを受けると読み込み済みのゾーンデータから目的の資源レコードを検索し、記述内容を応答メッセージとして返します。

　1つの資源レコードは1行で完結するように記述しますが、括弧でくくることで複数行わたる記述が可能になります。

　資源レコードは10種類ほどありますが、主な資源レコードの記述例を以下に示します。
前項の project.ed.jp ゾーンで、ホスト nsw をネームサーバーとして運用した場合を例としています。
※　ここでは資源レコードを省略形を用いずに記述しています。
　　実際の運用では省略形を用いることがほとんどで、もう少しスッキリしています。

Ⅲ．３．１．SOAレコード

　ネームサーバーが当該ゾーンの信頼できる情報源であることを表明します("権威がある"、"権威を持つ"と表現します)。SOAレコードは1つのゾーンデータファイル中に1つだけ記述します。

①②③④⑤⑥
project.ed.jp.86400INSOAnsw.project.ed.jp.adm.project.ed.jp. (
123
3h
15m
1w
1d )		;serial
;refresh
;retry
;expire
;minimum

①ownerこのゾーンの名称を記述します。
②ttlTime To Live. このレコードの情報がキャッシュされた場合の有効期間を秒単位で指定します。
③classinternet 用を表す先頭の2文字"IN"が入ります。現在はIN以外は使われていないようです。
④typeレコードタイプ。SOA(Start Of Authority)によって、このネームサーバーが project.ed.jp. ゾーンの権威を持つことになります。
⑤source-dnameこのゾーンに権威を持っているプライマリマスターネームサーバー※1のホスト名を記述します。ここでは nsw を指定しています。
ネームサーバーをホスト project に設定することも可能で、その場合は project.ed.jp. となります。実際にそのようにしているサイトも多数あります。
⑥mboxゾーン管理者のメールアドレス。最初のドット(.)は@に読み替えます。

　括弧でくくった部分の serial ～ expire は、スレーブネームサーバー※1が使用する情報で、ゾーンデータの世代管理番号(serial)や、更新確認の間隔(refresh)等を指定します。
　最後尾の minimum はネガティブキャッシュ※2のTTL(有効期間)を指定します。

　refresh～minimumは秒単位の数値を記述するか、例題のようにweek、day、hour、minuteの頭文字を使います。

※１プライマリマスターネームサーバー、スレーブネームサーバー
　システムの信頼性を確保するため、ネームサーバーは複数台での運用が推奨されています。
ネームサーバーはゾーンデータをどこから取得する(読み込む)かによって、プライマリマスターネームサーバーとスレーブネームサーバーの2種類に分類できます。
　ローカルのハードディスクに保存されているファイルから取得するのがプライマリマスターネームサーバーで、他のネームサーバーからネットワーク経由で取得するのがスレーブネームサーバーになります。
名前解決の動作において、プライマリマスターとスレーブの差はありません。
　スレーブネームサーバーはセカンダリマスターネームサーバーとも呼ばれます。

※２ネガティブキャッシュ
　ホストやドメインが存在しない時、"存在しない"という情報が問い合わせ元のネームサーバーにキャッシュされることがあります。 これをネガティブキャッシュといいます。


Ⅲ．３．２．NSレコード

　ゾーンに対して権威を持っているネームサーバーである事を宣言します。
①②③④⑤
project.ed.jp.86400INNSnsw.project.ed.jp.
project.ed.jp.86400INNSns2.project.ed.jp.

①ownerゾーンの名称を記述します。
②ttlSOAレコードの項参照。
③classSOAレコードの項参照。
④typeレコードタイプ。NS(Name Server)。
⑤name-server-dname<owner>欄に記述したゾーンの、権威あるネームサーバーのホスト名を記述します。

　2つのNSレコードで project.ed.jp ゾーンのネームサーバーが2台あることを示していますが、どちらがプライマリマスターネームサーバーであるかは意識しません。
※　前項の図では ns2.project.ed.jp は省略しています。

Ⅲ．３．３．Aレコード

　ホスト名に対応するIPアドレスを記述します。
①②③④⑤
nsw.project.ed.jp.86400INA10.23.145.241
ns2.project.ed.jp.86400INA10.23.145.242
ftp.windows.project.ed.jp.86400INA10.23.145.243
www.linux.project.ed.jp.86400INA10.23.145.244

①ownerホスト名を記述します。
②ttlSOAレコードの項参照。
③classSOAレコードの項参照。
④typeレコードタイプ。A(Address)。
⑤address<owner>欄に記述したホストのIPアドレスを記述します。

　ホスト名はAレコードによってIPアドレスへの変換(名前解決)が行われます。

Ⅲ．３．４．CNAMEレコード

　ホストの別名に対応した正規なホスト名を記述します。
例えばホスト nsw を使って www.project.ed.jp のwebサーバーを運用するような場合、CNAMEレコードを次のように記述します。
①②③④⑤
www.project.ed.jp.86400INCNAMEnsw.project.ed.jp.

①ownerホストの別名を記述します。
②ttlSOAレコードの項参照。
③classSOAレコードの項参照。
④typeレコードタイプ。CNAME(Canonical NAME)。
⑤canonical-name<owner>欄に記述したホストの正規名を記述します。

　別名(www.project.ed.jp.)に対する問い合わせがあると、正規名(nsw.project.ed.jp.)に置き換えて検索が再実行されます。

Ⅲ．３．５．PTRレコード

　IPアドレスに対応するホスト名を記述します。このレコードは逆引き(IPアドレスからホスト名を検索)で使用されます。
①②③④⑤
241.145.23.10.in-addr.arpa86400INPTRnsw.project.ed.jp.
244.145.23.10.in-addr.arpa86400INPTRwww.linux.project.ed.jp.

①owner逆引き用ドメイン名で定義されたIPアドレスを記述します。
②ttlSOAレコードの項参照。
③classSOAレコードの項参照。
④typeレコードタイプ。PTR(PoinTeR)。
⑤dname<owner>欄に記述したIPアドレスに対応したホスト名を記述します。
ただしここに記述できるのは正規名のみで別名は記述できません。

※　Ⅳ.１.１.正引きと逆引き および Ⅵ.２.名前解決-逆引き (ドメイン名検索) 参照。


Ⅲ．３．６．グルーレコード

　分割・委任したゾーン network.project.ed.jp のネームサーバーの情報も、親ゾーンの責任として記述する必要があります。
　子ゾーン側で運用しているネームサーバーのホスト名を、親ゾーン側ネームサーバーのNSレコードに記述する事で、委任している事実を認証します。

network.project.ed.jp.86400INNSnns.network.project.ed.jp.
nns.network.project.ed.jp.86400INA10.23.145.193

　この例では1行目のNSレコードで network.project.ed.jp ゾーンのネームサーバーのホスト名を示し、2行目のAレコードで対応するIPアドレスを示しています。
※　上記ではネームサーバー1件分のレコードのみ表示していますが、実際にはサブドメイン側で運用して
　　いるネームサーバー数に応じた数のレコードを記述します。

※　委任の関係を表すNSレコードとAレコードは、親子の間でその内容が同じでなければなりません。
※　2つのレコードは、子ゾーン管理者から親ゾーン管理者へ登録を依頼するのが実態のようです。

　委任先ゾーンに関するIPアドレス情報の提供は本来不要なのですが、委任先ネームサーバーのIPアドレスについては委任元のネームサーバーで解決する必要があります。
こうした目的のAレコードをグルーレコード(glue recode)と呼んでいます。

　ただし、network.project.ed.jp のネームサーバーがそのゾーンにない場合は、グルーレコードは不要になります。例えば network.project.ed.jp のネームサーバーが ns.example.co.jp にあるような場合は、
network.project.ed.jp.86400INNSns.example.co.jp.
と記述するだけです。
ns.example.co.jp.の名前解決(IPアドレス検索)は問い合わせ元に任せます。
※　このような場合、Aレコードを記述してはいけません。ネームサーバー(ns.example.co.jp)のIPアドレス
　　について何の権限もない(変更になっても連絡は来ない)からです。




≪　previous [[ アドレス検索 - DNSの話 ]] next　≫