• 4.2. データベースをゾーンに分ける方法 How the database is divided into zones
  

  • 4.2.1. 技術的事項 Technical considerations
    4.2.2. 管理上の事項 Administrative considerations
    

4. ネームサーバ

4.1. はじめに Introduction

4.2. データベースをゾーンに分ける方法 How the database is divided into zones

The domain database is partitioned in two ways: by class, and by ';cuts';
made in the name space between nodes.

ドメインデータベースの分割法は二つある:クラスによる方法と名前空間を ノードの間で「切る」という方法と。

The class partition is simple.  The database for any class is organized,
delegated, and maintained separately from all other classes.  Since, by
convention, the name spaces are the same for all classes, the separate
classes can be thought of as an array of parallel namespace trees.  Note
that the data attached to nodes will be different for these different
parallel classes.  The most common reasons for creating a new class are
the necessity for a new data format for existing types or a desire for a
separately managed version of the existing name space.

クラスによる分割は単純だ。 [以下、翻訳は省略]

Within a class, ';cuts'; in the name space can be made between any two
adjacent nodes.  After all cuts are made, each group of connected name
space is a separate zone.  The zone is said to be authoritative for all
names in the connected region.  Note that the ';cuts'; 
in the name space
may be in different places for different classes, the name servers may
be different, etc.

ひとつのクラスの中では名前空間の「切断」は任意の隣接したノードの間で行ってよい。 切断が行われた後に、連結されている名前空間のグループはひとつのゾーンとなる。 ゾーンは連結されている領域に対して権威をもつ。 名前空間の「切断」は異なるクラスの異なる場所にあるかもしれない。 また、ネームサーバも異なることがある、など。

These rules mean that every zone has at least one node, and hence domain
name, for which it is authoritative, and all of the nodes in a
particular zone are connected.  Given, the tree structure, every zone
has a highest node which is closer to the root than any other node in
the zone.  The name of this node is often used to identify the zone.

これらの規則が意味するのは、 各ゾーンはひとつ以上のノード、つまりドメイン名を持つことであり、 そのドメイン名に対して権威をもっていて、 さらに、ゾーン中のノードはすべてが連結されているということである。 ツリー構造をしているので、ゾーンにはゾーン中のどのノードよりも ルートにより近い最上位ノードがある。 このノードの名前がゾーンそのものを指すためによく使われる。

It would be possible, though not particularly useful, to partition the
name space so that each domain name was in a separate zone or so that
all nodes were in a single zone.  Instead, the database is partitioned
at points where a particular organization wants to take over control of
a subtree.  Once an organization controls its own zone it can
unilaterally change the data in the zone, grow new tree sections
connected to the zone, delete existing nodes, or delegate new subzones
under its zone.

特に役だつものではないが、名前空間を分割して 各ドメイン名が全て別のゾーンとすることも、 全てのノードを含むひとつのゾーンとすることも可能である。 それよりも、データベースは 組織が制御をひきとりたいような部分木に分れるように分割される。

組織がそれ自身のゾーンを制御しはじめれば、 ゾーン内のデータを独自に変更したり、 ゾーンに新しい木を増やしたり、既存のノードを削除したり、 自分の中に新しいサブゾーンを作って委譲したりすることができる。

If the organization has substructure, it may want to make further
internal partitions to achieve nested delegations of name space control.
In some cases, such divisions are made purely to make database
maintenance more convenient.

組織が下部構造を持つなら、 名前空間の制御を委譲するということを多段に行い、 さらに分割を行いたいであろう。

データベース管理がより簡単になるという 理由だけでこのような分割が行われることがある。

4.2.1. 技術的な考慮 Technical considerations

The data that describes a zone has four major parts:

ゾーンを記述するデータは大きく四つに分けられる：

   - Authoritative data for all nodes within the zone.

• - ゾーン内の全ノードの権威あるデータ。

   - Data that defines the top node of the zone (can be thought of
     as part of the authoritative data).

• - ゾーンの最上位ノードを定義するデータ （権威あるデータの一部であると考えられる）。

   - Data that describes delegated subzones, i.e., cuts around the
     bottom of the zone.

• - 委譲されたサブゾーンを記述するデータ、
  • すなわち、ゾーンの最下部での切断。

   - Data that allows access to name servers for subzones
     (sometimes called ';glue'; data).

• - サブゾーンのネームサーバへのアクセスを可能にするデータ （しばしば「グルー(のり)」と呼ばれる）。

All of this data is expressed in the form of RRs, so a zone can be
completely described in terms of a set of RRs.  Whole zones can be
transferred between name servers by transferring the RRs, either carried
in a series of messages or by FTPing a master file which is a textual
representation.

ここのすべてのデータは RR という形で表現される。 そのためゾーンは RRs の集合を使って完全に記述できる。

ネームサーバ間のゾーン全体を転送の転送は RRs の転送によって、あるいは メッセージ列としての転送、 もしくはテキスト表現であるマスターファイルの FTP などで可能である。

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.

ゾーンの権威あるデータとは ゾーンのトップノードからリーフかゾーン下端の切断のすぐ上のノードまでの 全てのノードに付属する全ての RRs のことにすぎない。

Though logically part of the authoritative data, the RRs that describe
the top node of the zone are especially important to the zone's
management.  These RRs are of two types: name server RRs that list, one
per RR, all of the servers for the zone, and a single SOA RR that
describes zone management parameters.

論理的には権威あるデータの一部ではあるが、 ゾーンの最上位ノードを記述する RRs はゾーンの管理に特に重要である。

この資源レコードは二つのタイプからなる: ネームサーバNS RRs (ゾーンのすべてのネームサーバを数えあげたもので、 ゾーンネームサーバ毎にひとつずつ)と、 ゾーン管理のパラメタを記述するSOA RR ひとつである。

The RRs that describe cuts around the bottom of the zone are NS RRs that
name the servers for the subzones. 

Since the cuts are between nodes,
these RRs are NOT part of the authoritative data of the zone, and should
be exactly the same as the corresponding RRs in the top node of the subzone. 

Since name servers are always associated with zone boundaries,
NS RRs are only found at nodes which are the top node of some zone. 
In the data that makes up a zone, NS RRs are found at the top node of the
zone (and are authoritative) and at cuts around the bottom of the zone
(where they are not authoritative), but never in between.

ゾーンの最下部に位置しゾーンカットを記述する RRs は サブゾーンのネームサーバを指す NS RRs である。

切断はノード間にあるので、 これらの RRs は当該ゾーンの権威あるデータの一部では「ない」。 そして、当該サブゾーンの最上位ノードについているはずの対応するNS RRs と完全に一致させなければならない。

ネームサーバというものは常にゾーン境界と結び付いてるので、 NS RRs はゾーンの最上位ノードにだけに見つかるはずのものである。 ゾーンを構成しているデータ中では、NS RRs は ゾーンの最上位ノードについている(権威がある)。 あるいはゾーンの底部のカットに現れることもある。(これらには権威はない) しかし、中間には決して現れることはない。

One of the goals of the zone structure is that any zone have all the
data required to set up communications with the name servers for any
subzones.  That is, parent zones have all the information needed to
access servers for their children zones.  The NS RRs that name the
servers for subzones are often not enough for this task since they name
the servers, but do not give their addresses.  In particular, if the
name of the name server is itself in the subzone, we could be faced with
the situation where the NS RRs tell us that in order to learn a name
server's address, we should contact the server using the address we wish
to learn.  
To fix this problem, a zone contains ';glue'; RRs
which are not
part of the authoritative data, and are address RRs for the servers.
These RRs are only necessary if the name server's name is ';below'; the
cut, and are only used as part of a referral response.

ゾーン構造の目標のひとつとして、 どのゾーンもそのサブゾーンのネームサーバとの交信に必要なすべてデータを 持つということがある。 すなわち、親ゾーンはその子ゾーンのサーバにアクセスするのに 必要な全ての情報を持つことである。

サブゾーンのサーバの名前を指す NS RRs だけではこの用途には不十分である。 それはサーバの名前は分ってもアドレスを示すものではないからである。

とりわけ、ネームサーバの名前がサブゾーンの内部のものである場合には 「ネームサーバのアドレスを知るためには、 知りたいはずのアドレスが分からないとそのネームサーバ（NS)に問い合わせることができない」 という場面に直面することとなる。

この問題を回避するために、ゾーンは 「グルー」 RRs を持ち、 (グルーはゾーンの権威あるデータの一部ではない。そして、ネームサーバのアドレス RRs である。) これらの RRs はネームサーバの名前がゾーンカットよりも「下」にある時にだけ 必要であり、参照返答(referral)の一部としてだけ用いられる。

4.2.2. 管理上の考慮 Administrative considerations

When some organization wants to control its own domain, the first step
is to identify the proper parent zone, and get the parent zone's owners
to agree to the delegation of control.  While there are no particular
technical constraints dealing with where in the tree this can be done,
there are some administrative groupings discussed in [RFC-1032] which
deal with top level organization, and middle level zones are free to
create their own rules.  For example, one university might choose to use
a single zone, while another might choose to organize by subzones
dedicated to individual departments or schools.  [RFC-1033] catalogs
available DNS software an discusses administration procedures.

組織が自身のドメインを管理しようとするときの最初の一歩は 正しく親ゾーンを知り、親ゾーンの所有者に管理を委譲してもらうよう 同意をとることである。 ドメイン木のどこで委譲してよいかに関しては特別な技術的制約はないが、 最上位組織を扱う[RFC-1032]で論じられている管理グループ分けは存在している。 さらに、中間レベルのゾーンは自身の規則を自由に作ってよい。 例えば、ある大学はゾーンをひとつだけ使うことを選ぶかもしれないし、 また別の大学は部門や各学校にサブゾーン専用に設けるやりかたを選ぶ かもしれない。 [RFC-1033]には利用可能なDNS ソフトウェアの一覧があり、 管理手順を論じている。

Once the proper name for the new subzone is selected, the new owners
should be required to demonstrate redundant name server support.  Note
that there is no requirement that the servers for a zone reside in a
host which has a name in that domain.  In many cases, a zone will be
more accessible to the internet at large if its servers are widely
distributed rather than being within the physical facilities controlled
by the same organization that manages the zone.  For example, in the
current DNS, one of the name servers for the United Kingdom, or UK
domain, is found in the US.  This allows US hosts to get UK data without
using limited transatlantic bandwidth.

新しいサブゾーンにふさわしい名前が選ばれたら、 新しい(ゾーン)所有者は複数のネームサーバを用意できることを 示すべきである。

ゾーンのためのサーバがそのドメインの名前を持ったホスト上にある 必要はないということに注意せよ。 多くの場合、ゾーンを維持する組織が管理する施設内にサーバがあるより、 広く分散されている方がインターネット一般からアクセスしやすいだろう。 例えば、現在の DNSではイギリス、つまり UK ドメインのための ネームサーバのひとつは US 内にある。 これにより、US のホストは 帯域の限定された太西洋横断回線を使わなくとも、 UK のデータを得られる。

As the last installation step, the delegation NS RRs and glue RRs
necessary to make the delegation effective should be added to the parent
zone.  The administrators of both zones should insure that the NS and
glue RRs which mark both sides of the cut are consistent and remain so.

インストールの最後のステップとして、親ゾーンには 委譲が効果をもつのに必要な委譲のための NS RRs と グルー RRs を 加えなければならない。 両方のゾーンの管理者は カットの両面を表わす NS と グルー RRs が一致していて、 いつまでもそうあり続けることを保証しなければならない。

---

2002-10-16 訳 前野年紀