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.
ネームサーバの最適な構造はホストオペレーティングシステムに依存する。 そして、再帰的サービスをサポートするとか、 リゾルバとデータベースを共有するとかして、 ネームサーバとリゾルバが統合されているかどうかにも依存する。 この節ではリゾルバとデータベースを共有するようなネームサーバーの 実装を考慮する。しかし、これらの事の多くはどのネームサーバにも 存在する。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 問合せサービスを止めるようなことはしてはならない。 同様に、ネームサーバーは再帰的なサービスはその要求を並列に処理しないなら 提供しようとしてはならない。ただし、ひとつのクライアントからの 要請を順番に処理したり、同じクライアントからの同じ要請は重複したものだと みなすのはかまわない。 ネームサーバーは マスターファイルからゾーンを再ロードする間とか データベースに更新されたゾーンを取り込む間とかに 問合せを過大に待たせてはならない。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.
- キャッシュは頻繁に更新されるので、システム再開時がもっとも壊れやすい。 キャッシュは期限切れの RR データで一杯になりえる。 どちらの場合も、ゾーンデータを乱すことなく容易に破棄できる。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.
データベース設計の主要な局面はネームサーバーがホストのクラッシュ障害 に対応できるような構造を選ぶ事である。 ネームサーバーがシステム障害に備えて保存すべき状態情報には カタログ構造（各ゾーンのリフレッシュ状態を含む） とゾーンデータそれ自身がある。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 は相対へ変換後の値が負であると、データは期限切れであり、 無視されるべきである。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最小限フィールドの変更があいまいな意味をもつことなく認め られるようにするためである。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でゾーンを送出している最中に新しい版が作られるても、 マスターは可能なら、古い版を送り続けるべきである。 どんな場合でも、ある部分は新しい版で、ある部分は古い版で あるようなものを送ってはならない。 もしゾーン転送を完了できないのであれば、 マスターはゾーン転送をしている接続をリセットするべきである。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. Inverse query and response example 6.4.2. 逆問合せと返答例
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 responsesThe 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で記述された補完サービスは削除された。 再設計されたサービスが将来利用可能になるかもしれない。