6. ネームサーバの実装 NAME SERVER IMPLEMENTATION

6.1. 構成 Architecture

The optimal structure for the name server will depend on the host
operating system and whether the name server is integrated with resolver
operations, either by supporting recursive service, or by sharing its
database with a resolver.  This section discusses implementation
considerations for a name server which shares a database with a
resolver, but most of these concerns are present in any name server.

ネームサーバの最適な構造はホストオペレーティングシステムに依存する。 そして、再帰的サービスをサポートするとか、 リゾルバとデータベースを共有するとかして、 ネームサーバとリゾルバが統合されているかどうかにも依存する。

この節ではリゾルバとデータベースを共有するようなネームサーバーの 実装を考慮する。しかし、これらの事の多くはどのネームサーバにも 存在する。

6.1.1. 制御 Control

A name server must employ multiple concurrent activities, whether they
are implemented as separate tasks in the host's OS or multiplexing
inside a single name server program.  It is simply not acceptable for a
name server to block the service of UDP requests while it waits for TCP
data for refreshing or query activities.  Similarly, a name server
should not attempt to provide recursive service without processing such
requests in parallel, though it may choose to serialize requests from a
single client, or to regard identical requests from the same client as
duplicates.  A name server should not substantially delay requests while
it reloads a zone from master files or while it incorporates a newly
refreshed zone into its database.

ネームサーバーはホストのOS上の複数のタスクとして実装されるか、 ひとつのネームサーバ内で複数処理を行うかして、 複数の同時並行処理を行えなければならない。 ネームサーバはリフレッシュ動作や問合せのために TCP データを待つ時に UDP 問合せサービスを止めるようなことはしてはならない。 同様に、ネームサーバーは再帰的なサービスはその要求を並列に処理しないなら 提供しようとしてはならない。ただし、ひとつのクライアントからの 要請を順番に処理したり、同じクライアントからの同じ要請は重複したものだと みなすのはかまわない。 ネームサーバーは マスターファイルからゾーンを再ロードする間とか データベースに更新されたゾーンを取り込む間とかに 問合せを過大に待たせてはならない。

6.1.2. データベース Database

While name server implementations are free to use any internal data
structures they choose, the suggested structure consists of three major
parts:

ネームサーバ実装者がどんな内部データ構造を選択するのも自由であるが、 構成例は3つの主要な部分からなる： 

   - A 'catalog' data structure which lists the zones available to
     this server, and a 'pointer' to the zone data structure.  The
     main purpose of this structure is to find the nearest ancestor
     zone, if any, for arriving standard queries.

   - Separate data structures for each of the zones held by the name server.

   - A data structure for cached data. (or perhaps separate caches for different classes)

All of these data structures can be implemented an identical tree
structure format, with different data chained off the nodes in different
parts: in the catalog the data is pointers to zones, while in the zone
and cache data structures, the data will be RRs.  In designing the tree
framework the designer should recognize that query processing will need
to traverse the tree using case-insensitive label comparisons; and that
in real data, a few nodes have a very high branching factor (100-1000 or
more), but the vast majority have a very low branching factor (0-1).

これらのデータ構造はすべて同一の木構造として実装できる。 異なる部分のノードからは異なるデータが繋がるものとして: カタログではデータはゾーンへのポインタであり、 ゾーンとキャッシュデータ構造では、データは RRs となる。 木機構を設計する際には設計者は次のことを認識するべきである。 問合せ処理では大文字小文字の違いを無視するラベル比較を使って ツリーを渡り歩く必要がある; 実データでは少数のノードは非常に多くの分岐ファクタ (100-1000 かそれ以上)を持つけれども、ほとんどは とても少ない分岐ファクタ(0-1)を持つ。 

One way to solve the case problem is to store the labels for each node
in two pieces: a standardized-case representation of the label where all
ASCII characters are in a single case, together with a bit mask that
denotes which characters are actually of a different case.  The
branching factor diversity can be handled using a simple linked list for
a node until the branching factor exceeds some threshold, and
transitioning to a hash structure after the threshold is exceeded.  In
any case, hash structures used to store tree sections must insure that
hash functions and procedures preserve the casing conventions of the
DNS.

文字ケース問題を解決する一つの方法は各ノードのラベルを2つ に分けることだ: ASCII 文字を大文字か小文字かどちらか一方だけに ケース標準化した表現のラベルと、 各文字でケースが実際とは異なっているものを表わすビットマスクとに。 分岐ファクタの広がりは分岐数がある閾値を超えるまでは ノードには単純なリンクドリストを使い、 閾値を超えたらハッシュ構造に移行することで扱かえる。 どちらの場合でも、 木部分をたくわえるハッシュ構造では ハッシュ関数と手続きが DNS のケースについての約束を保持すること を保証しすべきである。 

The use of separate structures for the different parts of the database
is motivated by several factors:

データベースの部分毎に別々の構造を用いることはいくつかの要素に起因する: 

   - The catalog structure can be an almost static structure that
     need change only when the system administrator changes the
     zones supported by the server.  This structure can also be
     used to store parameters used to control refreshing
     activities.

   - The individual data structures for zones allow a zone to be
     replaced simply by changing a pointer in the catalog.  Zone
     refresh operations can build a new structure and, when
     complete, splice it into the database via a simple pointer
     replacement.  It is very important that when a zone is
     refreshed, queries should not use old and new data
     simultaneously.

   - With the proper search procedures, authoritative data in zones
     will always 'hide', and hence take precedence over, cached
     data.

   - Errors in zone definitions that cause overlapping zones, etc.,
     may cause erroneous responses to queries, but problem
     determination is simplified, and the contents of one 'bad'
     zone can't corrupt another.

   - Since the cache is most frequently updated, it is most
     vulnerable to corruption during system restarts.  It can also
     become full of expired RR data.  In either case, it can easily
     be discarded without disturbing zone data.

A major aspect of database design is selecting a structure which allows
the name server to deal with crashes of the name server's host.  State
information which a name server should save across system crashes
includes the catalog structure (including the state of refreshing for
each zone) and the zone data itself.

データベース設計の主要な局面はネームサーバーがホストのクラッシュ障害 に対応できるような構造を選ぶ事である。 ネームサーバーがシステム障害に備えて保存すべき状態情報には カタログ構造（各ゾーンのリフレッシュ状態を含む） とゾーンデータそれ自身がある。

6.1.3. 時間 Time

Both the TTL data for RRs and the timing data for refreshing activities
depends on 32 bit timers in units of seconds.  Inside the database,
refresh timers and TTLs for cached data conceptually 'count down', while
data in the zone stays with constant TTLs.

RRs の TTL データとリフレッシュ活動のタイミングデータとは 秒単位の 32 ビットタイマに依存している。 データベース内部では、リフレッシュタイマとキャッシュデータのTTLは 概念的に言って「カウントダウン」され、 ゾーン内のデータは TTL は一定のままである。 

A recommended implementation strategy is to store time in two ways:  as
a relative increment and as an absolute time.  One way to do this is to
use positive 32 bit numbers for one type and negative numbers for the
other.  The RRs in zones use relative times; the refresh timers and
cache data use absolute times.  Absolute numbers are taken with respect
to some known origin and converted to relative values when placed in the
response to a query.  When an absolute TTL is negative after conversion
to relative, then the data is expired and should be ignored.

推奨される実装の戦略は時間を2つの方法で記憶することだ: 相対的増分と絶対時刻として。 そのためのひとつの方法は片方のタイプには 32ビットの正の値を使い、 他方には負の値を使うことだ。 ゾーンの RRs は相対時刻を使う; リフレッシュタイマとキャッシュデータは絶対時刻を使う。 絶対数はある既知の起点を基準にしていて、 問合せの返答に使われるときに、相対的な値に変換される。 絶対 TTL は相対へ変換後の値が負であると、データは期限切れであり、 無視されるべきである。

6.2. 標準問合せ処理 Standard query processing

The major algorithm for standard query processing is presented in
[RFC-1034].

標準問合せ処理のための主要なアルゴリズムは[RFC-1034]にある。 

When processing queries with QCLASS=*, or some other QCLASS which
matches multiple classes, the response should never be authoritative
unless the server can guarantee that the response covers all classes.

QCLASS=* または複数のクラスに合致する QCLASS 問合せを処理する時、 返答が全てのクラスをカバーしていることをサーバが保証できない限り 返答は権威あるものとはならない。 

When composing a response, RRs which are to be inserted in the
additional section, but duplicate RRs in the answer or authority
sections, may be omitted from the additional section.

返答を作る際に、付加節に入れられるべき RRs は 返答節や 権威節にあるRRs と重複するときには付加節から除いてよい。 

When a response is so long that truncation is required, the truncation
should start at the end of the response and work forward in the
datagram.  Thus if there is any data for the authority section, the
answer section is guaranteed to be unique.

切り落としが必要なほど返答が長い時は、切り落としは返答の末尾から始めて、 データグラムの前方へ行うべきである。 それゆえ、権威節にデータがあるなら、返答節はユニークなことが保証される。 

The MINIMUM value in the SOA should be used to set a floor on the TTL of
data distributed from a zone.  This floor function should be done when
the data is copied into a response.  This will allow future dynamic
update protocols to change the SOA MINIMUM field without ambiguous
semantics.

SOAのMINIMUM 値はゾーンから配布されるデータの TTL の下限を設定するために 使われるべきである。 この下限設定はデータが返答にコピーされる時に実行されるべきである。 これは将来、ダイナミック更新プロトコルで SOA最小限フィールドの変更があいまいな意味をもつことなく認め られるようにするためである。

6.3. ゾーンの更新と再ロード処理

Zone refresh and reload processing 

In spite of a server's best efforts, it may be unable to load zone data
from a master file due to syntax errors, etc., or be unable to refresh a
zone within the its expiration parameter.  In this case, the name server
should answer queries as if it were not supposed to possess the zone.

サーバが最善の努力しても、 マスターファイルの構文誤りなどによってゾーンデータをロードできない ことがある。 また、期間満了パラメタの期間内にゾーンのリフレッシュができないことも ある。 この場合、ネームサーバーはそのゾーンを所有していなかったかのように、 問合せに答えるべきである。 

If a master is sending a zone out via AXFR, and a new version is created
during the transfer, the master should continue to send the old version
if possible.  In any case, it should never send part of one version and
part of another.  If completion is not possible, the master should reset
the connection on which the zone transfer is taking place.

マスターがAXFRでゾーンを送出している最中に新しい版が作られるても、 マスターは可能なら、古い版を送り続けるべきである。 どんな場合でも、ある部分は新しい版で、ある部分は古い版で あるようなものを送ってはならない。 もしゾーン転送を完了できないのであれば、 マスターはゾーン転送をしている接続をリセットするべきである。

6.4. 逆問合せ（任意実装) Inverse queries (Optional)

Inverse queries are an optional part of the DNS.  Name servers are not
required to support any form of inverse queries.  If a name server
receives an inverse query that it does not support, it returns an error
response with the 'Not Implemented' error set in the header.  While
inverse query support is optional, all name servers must be at least
able to return the error response.

逆問合せは DNS の任意実装の部分である。 ネームサーバは逆問合せ形式の実装を要求されない。 ネームサーバは実装していない逆問合せを受け取ったとき、 ヘッダー部分に「実装されていない」エラーを設定したエラー返答を返す。 逆問合せの実装は任意であるが、 すべてのネームサーバーは少なくともエラー返答を返せなければならない。

[以下、翻訳は省略]

6.4.1. 逆の質問と返答の中身

The contents of inverse queries and responses 

Inverse queries reverse the mappings performed by standard query
operations; while a standard query maps a domain name to a resource,
an inverse query maps a resource to a domain name.  For example,
a standard query might bind a domain name to a host address;
the corresponding inverse query binds the host address to a domain name.

Inverse queries take the form of a single RR in the answer section of
the message, with an empty question section.  The owner name of the
query RR and its TTL are not significant.  The response carries
questions in the question section which identify all names possessing
the query RR WHICH THE NAME SERVER KNOWS.  Since no name server knows
about all of the domain name space, the response can never be assumed to
be complete.  Thus inverse queries are primarily useful for database
management and debugging activities.  Inverse queries are NOT an
acceptable method of mapping host addresses to host names; use the IN-
ADDR.ARPA domain instead.

Where possible, name servers should provide case-insensitive comparisons
for inverse queries.  Thus an inverse query asking for an MX RR of
'Venera.isi.edu' should get the same response as a query for
'VENERA.ISI.EDU'; an inverse query for HINFO RR 'IBM-PC UNIX' should
produce the same result as an inverse query for 'IBM-pc unix'.  However,
this cannot be guaranteed because name servers may possess RRs that
contain character strings but the name server does not know that the
data is character.

When a name server processes an inverse query, it either returns:

   1. zero, one, or multiple domain names for the specified
      resource as QNAMEs in the question section

   2. an error code indicating that the name server doesn't support
      inverse mapping of the specified resource type.

When the response to an inverse query contains one or more QNAMEs, the
owner name and TTL of the RR in the answer section which defines the
inverse query is modified to exactly match an RR found at the first
QNAME.

RRs returned in the inverse queries cannot be cached using the same
mechanism as is used for the replies to standard queries.  One reason
for this is that a name might have multiple RRs of the same type, and
only one would appear.  For example, an inverse query for a single
address of a multiply homed host might create the impression that only
one address existed.

6.4.2. 逆問合せと返答例

6.4.2. Inverse query and response example 

The overall structure of an inverse query for retrieving the domain
name that corresponds to Internet address 10.1.0.52 is shown below:

                         +-----------------------------------------+
           Header        |          OPCODE=IQUERY, ID=997          |
           ヘッダ        +-----------------------------------------+
          Question       |                 <empty>                 |
            質問         +-----------------------------------------+
           Answer        |        <anyname> A IN 10.1.0.52         |
            返答         +-----------------------------------------+
          Authority      |                 <empty>                 |
            正式         +-----------------------------------------+
         Additional      |                 <empty>                 |
            追加         +-----------------------------------------+

This query asks for a question whose answer is the Internet style
address 10.1.0.52.  Since the owner name is not known, any domain name
can be used as a placeholder (and is ignored).  A single octet of zero,
signifying the root, is usually used because it minimizes the length of
the message.  The TTL of the RR is not significant.  The response to
this query might be:

                         +-----------------------------------------+
           Header        |         OPCODE=RESPONSE, ID=997         |
           ヘッダ        +-----------------------------------------+
          Question       |QTYPE=A, QCLASS=IN, QNAME=VENERA.ISI.EDU |
            質問         +-----------------------------------------+
           Answer        |  VENERA.ISI.EDU  A IN 10.1.0.52         |
            返答         +-----------------------------------------+
          Authority      |                 <empty>                 |
            正式         +-----------------------------------------+
         Additional      |                 <empty>                 |
            追加         +-----------------------------------------+

Note that the QTYPE in a response to an inverse query is the same as the
TYPE field in the answer section of the inverse query.  Responses to
inverse queries may contain multiple questions when the inverse is not
unique.  If the question section in the response is not empty, then the
RR in the answer section is modified to correspond to be an exact copy
of an RR at the first QNAME.

6.4.3. 逆問合せ処理 Inverse query processing

Name servers that support inverse queries can support these operations
through exhaustive searches of their databases, but this becomes
impractical as the size of the database increases.  An alternative
approach is to invert the database according to the search key.

逆問合せを実装するネームサーバはデータベースのしらみ潰し探索により、 この操作を実装できるが、データベースが大きくなると非実用的である。 代わりの方法は探索キーを使って、データベースを反転することである。 

For name servers that support multiple zones and a large amount of data,
the recommended approach is separate inversions for each zone.  When a
particular zone is changed during a refresh, only its inversions need to
be redone.

Support for transfer of this type of inversion may be included in future
versions of the domain system, but is not supported in this version.

6.5. 補完問合せと返答 Completion queries and responses

The optional completion services described in RFC-882 and RFC-883 have
been deleted.  Redesigned services may become available in the future.

RFC-882とRFC-883で記述された補完サービスは削除された。 再設計されたサービスが将来利用可能になるかもしれない。

2002-08-01 訳 前野年紀