The top levels of the recommended resolver algorithm are discussed in [RFC-1034]. This section discusses implementation details assuming the database structure suggested in the name server implementation section of this memo.
トップレベルの推奨されるリゾルバアルゴリズムは[RFC-1034]に 述べられている。 この節ではこのメモのネームサーバ実装節で提案したデータベース構造を想定した 実装の詳細を述べる。The first step a resolver takes is to transform the client's request, stated in a format suitable to the local OS, into a search specification for RRs at a specific name which match a specific QTYPE and QCLASS. Where possible, the QTYPE and QCLASS should correspond to a single type and a single class, because this makes the use of cached data much simpler. The reason for this is that the presence of data of one type in a cache doesn't confirm the existence or non-existence of data of other types, hence the only way to be sure is to consult an authoritative source. If QCLASS=* is used, then authoritative answers won't be available.
リゾルバの最初のステップはローカルOS向けの形式で表わされた クライアント要求を RRs の検索仕様に変換することである。 (指定した名前を持ち、QTYPE と QCLASS に適合するもの) 可能なら、QTYPE と QCLASS はひとつのタイプとクラスに対応すべきである。 なぜなら、それがキャッシュデータの利用を単純にするからである。 その理由はキャッシュ中のある種類のデータの存在は他の種類のデータの 存在/非存在の確認には使えないからで、それ故、確認の唯一の方法は権威ある 情報源を調べることである。 もし QCLASS=* が使われるなら、権威ある答は利用できない。Since a resolver must be able to multiplex multiple requests if it is to perform its function efficiently, each pending request is usually represented in some block of state information. This state block will typically contain:
リゾルバはその機能を効率的に実行するには、複数の要求を同時に 扱かえなければならないので、 未処理の問合せは状態情報として通常表現される この状態情報は一般に以下のようなものだ：- A timestamp indicating the time the request began. The timestamp is used to decide whether RRs in the database can be used or are out of date. This timestamp uses the absolute time format previously discussed for RR storage in zones and caches. Note that when an RRs TTL indicates a relative time, the RR must be timely, since it is part of a zone. When the RR has an absolute time, it is part of a cache, and the TTL of the RR is compared against the timestamp for the start of the request.
- 要求が来た時刻を示すタイムスタンプ。 タイムスタンプはデータベース中の RRs が使えるものか、 期限切れかを決めるために使う。 このタイムスタンプは以前に述べたゾーンとキャッシュ中の RR 保存用の絶対時刻形式を使う。 RRs の TTL が相対的な時を示す時は、 RR がゾーンの一部なので、 RR は最新に違いないことに注意せよ。 RR が絶対時刻を持つ時は、それはキャッシュの一部であり、 RR の TTL は要求開始時刻のタイムスタンプと比較される。Note that using the timestamp is superior to using a current time, since it allows RRs with TTLs of zero to be entered in the cache in the usual manner, but still used by the current request, even after intervals of many seconds due to system load, query retransmission timeouts, etc.
タイムスタンプを使うことは現在時刻を使うことに勝っている ことに注意せよ。 TTL がゼロの RRs を通常の方法でキャッシュに入れることが できるからだ。 システムの負荷や問合せの再送タイムアウトなどによる 数秒間の期間のあとでさえ現在処理中の要求に使われているが。- Some sort of parameters to limit the amount of work which will be performed for this request.
- 要求に対して行う仕事量を制限するある種のパラメタThe amount of work which a resolver will do in response to a client request must be limited to guard against errors in the database, such as circular CNAME references, and operational problems, such as network partition which prevents the resolver from accessing the name servers it needs. While local limits on the number of times a resolver will retransmit a particular query to a particular name server address are essential, the resolver should have a global per-request counter to limit work on a single request. The counter should be set to some initial value and decremented whenever the resolver performs any action (retransmission timeout, retransmission, etc.) If the counter passes zero, the request is terminated with a temporary error.
循環した CNAME 参照のようなデータベースのエラーとか、 リゾルバがネームサーバにアクセスするのを妨げる ネットワークの分割などの運用上の問題などから防御するために リゾルバがクライアント要求に応えるためにする仕事の量は 制限されなければならない。 リゾルバがひとつのネームサーバアドレスに問合せを 再送する回数のローカルな上限が不可欠である一方、 リゾルバは要求ごとの仕事を制限するために、 グローバルなカウンタを持つべきである。The counter should be set to some initial value and decremented whenever the resolver performs any action (retransmission timeout, retransmission, etc.) If the counter passes zero, the request is terminated with a temporary error.
カウンタはある初期値に設定され、リゾルバがなにか動作する (再送タイムアウト、再送など)たびに減算される。 カウンタがゼロになったら要求は一時的なエラーで終了となる。Note that if the resolver structure allows one request to start others in parallel, such as when the need to access a name server for one request causes a parallel resolve for the name server's addresses, the spawned request should be started with a lower counter. This prevents circular references in the database from starting a chain reaction of resolver activity.
リゾルバの構造がひとつの要求が他を並列に開始することを許すなら、 例えばあるネームサーバへのアクセスする必要がある要求が ネームサーバーのアドレスを並列に解決する仕事を発生するように、 生成された要求はより小さいカウンター値で始められるべき事に注意せよ。 これはデータベースの循環参照がリゾルバ活動の連鎖反応を起すのを 防止する。- The SLIST data structure discussed in [RFC-1034].
- サーバリストデータ構造は[RFC-1034]で述べらている。This structure keeps track of the state of a request if it must wait for answers from foreign name servers.
この構造は外部ネームサーバの返答を待つ要求にたいしては 要求の状態を保持する。As described in [RFC-1034], the basic task of the resolver is to formulate a query which will answer the client's request and direct that query to name servers which can provide the information. The resolver will usually only have very strong hints about which servers to ask, in the form of NS RRs, and may have to revise the query, in response to CNAMEs, or revise the set of name servers the resolver is asking, in response to delegation responses which point the resolver to name servers closer to the desired information. In addition to the information requested by the client, the resolver may have to call upon its own services to determine the address of name servers it wishes to contact.
[RFC-1034]にあったように、 リゾルバの基本的な仕事は クライアントの要求に答えるはずの問合せを生成して、 情報を提供できるネームサーバに向けて問合せる事である。 リゾルバは通常どのサーバーに尋ねるべきか、 NS RRs の形式でヒントを持つだけであり、 CNAME に応えて問合せを修正したり、 望ましい情報により近いネームサーバを示す委譲応答に応えて リゾルバが尋ねるべきネームサーバの集合を修正したりする必要がある。 クライアントが求める情報のほかに、 リゾルバは連絡を取りたいネームサーバのアドレスを知るために 自身のためのサービスを開始しなければならないことがある。In any case, the model used in this memo assumes that the resolver is multiplexing attention between multiple requests, some from the client, and some internally generated. Each request is represented by some state information, and the desired behavior is that the resolver transmit queries to name servers in a way that maximizes the probability that the request is answered, minimizes the time that the request takes, and avoids excessive transmissions. The key algorithm uses the state information of the request to select the next name server address to query, and also computes a timeout which will cause the next action should a response not arrive. The next action will usually be a transmission to some other server, but may be a temporary error to the client.
どちらにせよ、このメモで使われるモデルでは クライアントからの要求や内部で生成された要求など、 リゾルバは複数の要求間の整理処理をすることを仮定する。 各要求は状態情報により表現される。 リゾルバの望ましい行動とは 要求の答がえられる可能性を最大にするよう、 要求にかかる時間を最小にするよう、 また過大な送信を避けるようにして、 ネームサーバに問合せを送ることである。 キーアルゴリズムは 要求の状態情報を使って 問合せすべき次のネームサーバアドレスを選ぶ。 そして、返事がなかった場合に、次の行動を起こすべきタイムアウトを計算する。 次の行動とは通常は他のサーバーへの通信であるが、 クライアントへの一時的エラー通知かもしれない。The resolver always starts with a list of server names to query (SLIST). This list will be all NS RRs which correspond to the nearest ancestor zone that the resolver knows about. To avoid startup problems, the resolver should have a set of default servers which it will ask should it have no current NS RRs which are appropriate. The resolver then adds to SLIST all of the known addresses for the name servers, and may start parallel requests to acquire the addresses of the servers when the resolver has the name, but no addresses, for the name servers.
リゾルバは常に問合せるべきサーバ名のリスト(SLIST)から始める。 このリストはリゾルバが知る最も近い祖先ゾーンに対応するすべての NS RRs だろう。 起動時の問題を避けるため、 リゾルバは尋ねるべきデフォルトのサーバの集合を持つべきである。 それはもし適切な現在の NS RRsがないときに問合せに使われる。 それから、リゾルバは SLIST にネームサーバの既知の全てのアドレスを加える。 そして、ネームサーバの名前はあるが、アドレスを知らないときには サーバのアドレスを獲得するために平行した要求を送る。To complete initialization of SLIST, the resolver attaches whatever history information it has to the each address in SLIST. This will usually consist of some sort of weighted averages for the response time of the address, and the batting average of the address (i.e., how often the address responded at all to the request). Note that this information should be kept on a per address basis, rather than on a per name server basis, because the response time and batting average of a particular server may vary considerably from address to address. Note also that this information is actually specific to a resolver address / server address pair, so a resolver with multiple addresses may wish to keep separate histories for each of its addresses. Part of this step must deal with addresses which have no such history; in this case an expected round trip time of 5-10 seconds should be the worst case, with lower estimates for the same local network, etc.
SLIST の初期化を完了するために、リゾルバは SLIST の各アドレスに しるかぎりの履歴情報を付加する。 これは通常、アドレスから応答時間の重みつき平均とアドレスの打率/返答率 (つまり、そのアドレスがどのぐらい要求に応答したか)とからなる。 この情報はネームサーバ毎ではなくアドレス毎に保持されるべきであり、 それはサーバの応答時間や返答率はアドレス毎に異なるからである ということに注意せよ。 またこの情報はリゾルバアドレスとサーバーアドレスの対に特有なことに注意せよ。 それゆえ、複数アドレスを持つリゾルバは その各アドレス毎の履歴の保持を望むかもしれない。 このステップでは履歴を持たないアドレスも扱わなくてはならない; この場合、往復時間期待値 が 最悪の場合 5-10 秒であると想定し、 ローカルネットワークではより小さく見積る。Note that whenever a delegation is followed, the resolver algorithm reinitializes SLIST.
委譲が行われていたら、リゾルバアルゴリズムは SLIST を再初期 化することに注意せよ。The information establishes a partial ranking of the available name server addresses. Each time an address is chosen and the state should be altered to prevent its selection again until all other addresses have been tried. The timeout for each transmission should be 50-100% greater than the average predicted value to allow for variance in response.
その情報は利用可能なネームサーバアドレスの部分順序を確立する。 アドレスが選択される度に状態を変更して、 他のすべてのアドレスが試されるまでは同じアドレスを選択しないようにする。 各通信のタイムアウトは応答の変動を考慮して、 平均の予測値より 50-100% 大きくすべきである。Some fine points:
ある細かいポイント：- The resolver may encounter a situation where no addresses are available for any of the name servers named in SLIST, and where the servers in the list are precisely those which would normally be used to look up their own addresses. This situation typically occurs when the glue address RRs have a smaller TTL than the NS RRs marking delegation, or when the resolver caches the result of a NS search. The resolver should detect this condition and restart the search at the next ancestor zone, or alternatively at the root.
- リゾルバは SLIST にあるすべてのネームサーバが利用不可能であり、 リスト中のサーバーがそのサーバ自身のアドレスを問合わせるのに 使われるものであるような状況に遭遇することがある。 この状況はグルーアドレス RRsのTTL が委譲を行う NS RRs のTTL より小さいときや、リゾルバが NS 検索の結果をキャッシュ してる場合におきる。 リゾルバはこの条件を検出して、次の祖先のゾーンまたは代わりとして ルートから検索を再開すべきである。- If a resolver gets a server error or other bizarre response from a name server, it should remove it from SLIST, and may wish to schedule an immediate transmission to the next candidate server address.
- リゾルバはネームサーバからサーバエラーや他の奇異な返答を得たら、 そのネームサーバを SLIST から取り除くべきであり、 次の候補サーバアドレスに即刻送信するよう計画するかもしれない。The first step in processing arriving response datagrams is to parse the response. This procedure should include:
受け取った返答データグラムを処理する最初の手順は返答を解析することである。 この手続きが含むべきものは：- Check the header for reasonableness. Discard datagrams which are queries when responses are expected.
- ヘッダが妥当か検査する。返答が期待されるときには 問合せであるデータグラムは破棄する。- Parse the sections of the message, and insure that all RRs are correctly formatted.
- メッセージの各部を解析し、すべての RRsの形式が正しい ことを確認する。- As an optional step, check the TTLs of arriving data looking for RRs with excessively long TTLs. If a RR has an excessively long TTL, say greater than 1 week, either discard the whole response, or limit all TTLs in the response to 1 week.
- 省略可能の手順として、著しく長い TTL の RRsがないか 受信データの TTL を検査せよ。 もし RRs の TTL が著しく長いなら、例えば１週間以上なら、 返答全体を捨てるか、返答のすべての TTL を１週間に制限せよ。The next step is to match the response to a current resolver request. The recommended strategy is to do a preliminary matching using the ID field in the domain header, and then to verify that the question section corresponds to the information currently desired. This requires that the transmission algorithm devote several bits of the domain ID field to a request identifier of some sort. This step has several fine points:
次の手順では 現在のリゾルバの要求と返答をつきあわせる。 推奨される戦略は ドメインヘッダの IDフィールドを使って、予備つきあわせを行い、 次に質問節が現在の希望する情報に対応することを確かめる事である。 これは送信アルゴリズムがドメイン ID の数ビットを なんらかの要求識別子のために使うことが必要になる。 この手順の細かいポイントは：- Some name servers send their responses from different addresses than the one used to receive the query. That is, a resolver cannot rely that a response will come from the same address which it sent the corresponding query to. This name server bug is typically encountered in UNIX systems.
- 問合せを受信するのに使ったのとは異なるアドレスから 返答を送るネームサーバがある。 つまり、リゾルバは問合せを送ったのと同じアドレスから返答が 来るということを使えない。 このネームサーバのバグは典型的にはUNIXシステムで起きる。- If the resolver retransmits a particular request to a name server it should be able to use a response from any of the transmissions. However, if it is using the response to sample the round trip time to access the name server, it must be able to determine which transmission matches the response (and keep transmission times for each outgoing message), or only calculate round trip times based on initial transmissions.
- リゾルバはネームサーバにリクエストを再送したなら、どれの返答 でも使えるべきである。しかし、ネームサーバにアクセスするときの 往復時間をはかるために返答を使うのなら、 どの送信とどの返答が対応するのか決定できるようにするか (そして各送信メッセージの送信時刻を保持する)、 最初の送信に基づいた往復時間を計算しなければならない。- A name server will occasionally not have a current copy of a zone which it should have according to some NS RRs. The resolver should simply remove the name server from the current SLIST, and continue.
- ネームサーバはある NS RRsに従えば持つはずのゾーンの最新のコピーを 時折持たないことがある。 リゾルバは単にネームサーバを現在の SLIST から取り除いて、 仕事を続ける。In general, we expect a resolver to cache all data which it receives in responses since it may be useful in answering future client requests. However, there are several types of data which should not be cached:
一般に、将来のクライアントからの要求に答える際に 有用かもしれないので、返答として受け取ったすべてのデータを リゾルバがキャッシュすることを期待する。 しかしながら、キャッシュすべきではない種類のデータもある：- When several RRs of the same type are available for a particular owner name, the resolver should either cache them all or none at all. When a response is truncated, and a resolver doesn't know whether it has a complete set, it should not cache a possibly partial set of RRs.
- ある所有者名に対する同じタイプの 複数の RRsがあるとき、 リゾルバはそれら全てをキャッシュするか、まったくキャッシュしないか のどちかである。 返答が切り詰められ、完全な返答集合かどうか不明のときは 部分的な RRs集合はキャッシュすべきではない。- Cached data should never be used in preference to authoritative data, so if caching would cause this to happen the data should not be cached.
- キャッシュされたデータは権威あるデータより優先されべきではない。 もしこれが生じるのであれば、データはキャッシュしてはならない。- The results of an inverse query should not be cached.
- 逆問合せの結果はキャッシュすべきではない。- The results of standard queries where the QNAME contains "*" labels if the data might be used to construct wildcards. The reason is that the cache does not necessarily contain existing RRs or zone boundary information which is necessary to restrict the application of the wildcard RRs.
- ワイルドカードを作るのに使われるかもしれないなら、 QNAME が "*"ラベルを含む標準問合せの結果。 その理由はキャッシュはワイルドカード RRsの適用を制限するのに 必要な存在している RRs やゾーン境界の情報をもつとは限らないからである。- RR data in responses of dubious reliability. When a resolver receives unsolicited responses or RR data other than that requested, it should discard it without caching it. The basic implication is that all sanity checks on a packet should be performed before any of it is cached.
- 信頼性の疑わしい返答中の RR データ。 望んだのではない返答やリゾルバが要求したもの以外のRR データを受けとったら、 それはキャッシュせずに捨てるべきである。 基本的な含意はキャッシュする前には すべてのパケットの安全点検を行うべきであるということだ。In a similar vein, when a resolver has a set of RRs for some name in a response, and wants to cache the RRs, it should check its cache for already existing RRs. Depending on the circumstances, either the data in the response or the cache is preferred, but the two should never be combined. If the data in the response is from authoritative data in the answer section, it is always preferred.
関連して、 リゾルバがある名前についての RRs 集合を返答にもらったとき、 それをキャッシュしようとするなら、 既存の RRs がキャッシュされていないか、検査すべきである。 状況によって、返答中のデータか、キャッシュのどちらかが 優先されるが、この2つは統合してはならない。 もし返答のデータが回答節中の権威あるデータからのものなら、 常に優先される。